The and parts of the XML request are used to help identify the device, application and user. Other than the Application name and Application Version fields, these must not be hard- coded to pre-set values within the App – they must be determined from the actual device the App is installed on.

For each transaction request a reference is created using these idenfication values. For any Continuous-Authority requests (recurring payments), the reference must match the reference generated for the initial transaction. If it does not match, then the request will be declined.

WebView browser headers

Transaction requests where the App captured the card details and where that request is using the E-Commerce transaction class, must provide the User Agent and Accept headers that will be used within any subsequent WebView request.

These headers are transmitted to the 3-D Secure system as part of the card enrolment check. Should 3-D Secure verification be required, the issuers systems may compare any headers received from within the WebView at that stage with the headers used during the enrolment check. If these do not match, some card issuers may reject the authentication request, which would cause the transaction to decline.

The methods used when sending XML requests to the gateway often use different headers to those within a WebView session, as such you should ensure that you obtain the correct headers before
sending the request. In some systems this may only be possible by creating a WebView element, intercepting the headers from the http request it was going to send out, and closing the WebView before it actually makes any communication. This can be done by attaching event handlers to the appropriate stage of the WebView. This check should be done either at application startup, or just prior to making a transaction request that will require these headers. It should not be done at application installation time, as the browser details used within the WebView may be updated after the application is installed.

Location Information

Where possible, you should also provide the current location of the user as provided by the location services with the device. These can be supplied using the following fields:

<mobile>
    ...
   <location>
        <lat>Current latitude</lat>
        <long>Current longitude</long>
    </location>
     ...
</mobile>