Skip to main content

Payment Page Integration Guide

1. Welcome

Optomany and DNA Payments have combined to produce a feature rich solution for the processing of ecommerce transactions. The axept® Checkout v3 solution has been designed to operate either as a full-page redirect or the provision of the payment form within a JavaScript lightbox which allows the consumer to stay on the host sites checkout page. Both operating modes see axept® Checkout v3 handle the sensitive card information meaning that the host website never has access to full card numbers.

The solution includes a simple integration which has been specifically designed to allow merchants to add axept® Checkout v3 to the checkout of their website quickly and seamlessly. The axept® Checkout v3 user interface can also be branded to match the look and feel of the merchant checkout page, giving the consumer further comfort when making payment.

This document is intended to provide the reader with everything needed to implement an integration to axept® Checkout v3, including the integration approval process required prior to processing live transactions. As with all solutions provided support is provided during this process, contact details can be found at the end of this document.

2. Supported Payment Methods

The axept® Checkout v3 solution currently supports the below payment methods.

Credit and Debit Cards
VISAVisa Credit
Visa Debit
VISAMastercard Credit
Mastercard Debit
MaestroMaestro
American ExpressAmerican Express
Diners/DiscoverDiners/Discover

This card support is backed by the schemes Payer Authentication/3D Secure services which are supported to the latest standards.

Payer Authentication SchemeCard Scheme
Verified by VISAVerified by VISA (VBV)VISA Credit & VISA Debit Cards
MasterCard SecureCodeMasterCard SecureCodeMasterCard Credit, MasterCard Debit and Maestro Cards
American Express SafekeyAmerican Express SafekeyAmerican Express Cards

Development of the axept® Checkout v3 solution is ongoing and additional payment methods will be added in the future. Please contact Optomany to keep updated with developments.

3. Before Starting

Before starting to integrate to the axept® Checkout v3 solution the following will need to be obtained from Optomany using the contact details at the end of this document.

  • Test Account
    • Allowing processing using a simulated acquirer connection.
    • Integrators will be issued with;
      • TerminalID
      • ClientID
      • ClientSecret
  • Test Login to Portal
    • Allows the checking of test transactions processed during the development and test process.
  • Test Scripts
    • Ensures that the requirements of the integration testing are fully understood.

The integration support team operate a ticket management solution, as soon as your query is submitted a ticket is created - please ensure you reference all subsequent queries with the ticket reference to speed up responses.

4. Integrating to axept® Checkout v3

The integration to axept® Checkout v3 is broken down into four stages.

PHOTO

The Four Stages of Processing a Transaction
Step 1:
Authentication
Before a transaction can be processed the host website must complete authentication with axept® Checkout v3. This authentication is only valid for the transaction currently in progress and must be re-run before attempting the next.

This process is covered in 5.2 Step One: Authentication
Step 2:
Redirection for Payment
Once the authentication has been completed the host website can redirect the consumer to axept® Checkout v3. This re-direction is achieved either via a full-page redirect or using the JavaScript lightbox. The host website is in control of which method is used.

This process is covered in 5.3 Step Two: Redirection for Payment
Step 3:
Payment Result
Cl After the consumer has entered their card details and the authorisation result has been received axept® Checkout v3 will confirm this result to the host website. This result is then recorded against the consumer’s order.

This process is covered in 5.4 Step Three: Receiving the Payment Result
Step 4:
Redirection to Host
After the transaction process is complete axept® Checkout v3 will redirect the consumer back to the host site using the URL(s) provided in the request. The host website will then complete the checkout.

This process is covered in 5.5 Step Four: Redirection to Host

4.1. Operation Modes - “scope”

axept® Checkout v3 currently supports three different operation modes which are referred to individually within this document as “scope”.

4.1.1. Full Re-Direct

The consumer is redirected to the axept® Checkout v3 payment page hosted by Optomany. As this is a full re-direct the consumer will leave the merchant site whilst the payment is being made and re-directed back once complete. Using this method ensures that the merchant site has no visibility of any card data as all sensitive data is entered on the hosted page.

The default user interface for the re-direct is shown below.

PHOTO

4.1.2. JavaScript Lightbox (iFrame)

As an alternative approach to the full re-direct axept® Checkout v3 offers the ability for the merchant to display a JavaScript Lightbox window on their site to accept payment. This approach is often preferred to a re-direct as it allows the consumer to appear to stay on the merchant site while making payment (the site will still show in the background).

axept® Checkout v3 offers two configuration options around the provision of the JavaScript Lightbox. The first of which sees the content of the JavaScript Lightbox populated via an iFrame. This allows Optomany to host the fields where the data is being entered and as such provides the protection from sensitive card data for the merchant.

PHOTO

4.1.3. JavaScript Lightbox (Locally Hosted)

The second JavaScript Lightbox option looks identical to the consumer but has one key difference - the code used to generate the data entry fields are hosted locally on the merchant website rather than hosted by Optomany.

PHOTO

4.1.4. Branding

It is possible to apply custom branding to all the above operation modes for a merchant or partner, please contact Optomany to discuss further.

4.2. Step One: Authentication

Prior to attempting to process a transaction the host website must complete authentication with the DNA platform. The authentication process is unique for each transaction and utilises the test account credentials which are supplied following the configuration of the merchant test account, namely;

  • TerminalID
  • ClientID
  • ClientSecret

4.2.1. Authentication POST - Request

Authentication is completed via a POST request to the test URL shown below.

URL: https://test-oauth.dnapayments.com/oauth2/token

danger

The “client_secret” must always be stored securely. Do not send authorisation requests from the front-end as the user could access the data via the web browser’s console.

The POST must contain the below data.

Authentication Request
Field NameStateData TypeDescription
grant_typeMandatoryStringAuthorisation type required to confirm the action required.
  • client_credentials Obtain credentials required to process a transaction.
scopeMandatoryStringConfirm scope of the action to be performed with credentials.
  • payment integration_hosted Full re-direct.
  • payment integration_embedded JavaScript Lightbox - content delivered via iFrame.
  • payment integration_seamless JavaScript Lightbox - content hosted on merchant site.
  • webapi Transaction management.
client_idMandatoryStringProvided to the integrator following the successful creation of a test account.
client_secretMandatoryStringProvided to the integrator following the successful creation of a test account.
invoiceIdMandatoryStringOrder/invoice/transaction/basket number generated by the host website. This ID must be unique for this transaction.
amountMandatoryDecimalTotal amount of the order including decimal places where applicable. ‘Whole’ amounts (e.g. “1”) on a GBP account will be processed as £1.00.
currencyMandatoryStringCurrency of the transaction.
  • GBP Pound Sterling
terminalMandatoryStringProvided to the integrator following the successful creation of a test account.
postLinkOptionalURLMust be a fully qualified URL.

If provided this data is used for extra checking when the transaction request is received.
failurePostLinkOptionalURLMust be a fully qualified URL.

If provided this data is used for extra checking when the transaction request is received.
Example: Authentication Request (NodeJs)
var request = require("request");

var options = {
method: 'POST',
url: 'https://oauth.dnapayments.com/oauth2/token',
formData:
{
scope: 'payment integration_seamless',
client_id: 'ExampleShop',
client_secret: 'mFE454mEF6kmGb4CDDeN6DaCnmQPf4KLaF59GdqwP',
grant_type: 'client_credentials',
invoiceId: '1234567',
amount: '1',
currency: 'GBP',
terminal: 'b95c9d1f-132f-4e04-92d2-32335c7486ea'
}
};

request(options, function (error, response, body)
{
if (error) throw new Error(error);
console.log(body);
});

4.2.2. Authentication POST - Response

Following the receipt of a correctly formatted authorisation POST the DNA platform will respond with the below.

Field NameData TypeDescription
access_tokenStringAccess token provided by the DNA platform for this transaction. The token should be securely stored ready to be used in the transaction request.
expires_inIntegerNumber of seconds from generation until the access_token expires. If the token is not used before this time has passed a new token will need to be requested.
refresh_tokenStringReserved for future use.
scopeStringConfirmation of the scope(s) passed in the authorisation request.
token_typeStringType of token issued
  • Bearer Bearer token

An example response is shown below.

Example: Authentication Response
{
"access_token":"qy/ZWj049WHUZj+8i1pUwmYxswo4GXK+Z5",
"expires_in": 7200,
"refresh_token":"",
"scope":"payment integration_seamless",
"token_type":"Bearer"
}

4.3. Step Two: Redirection for Payment

Now that the authentication details have been successfully obtained a transaction can be started. As covered in the introduction, axept® Checkout v3 offers two differing payment flows which can be used as required by the host website.

Full RedirectThe consumer will be redirected from the host website to the axept® Checkout v3. The consumer will enter their card data on this page and request authorisation.

Once complete the consumer will be shown the result and then redirected to the applicable URL (depending on result) from the host websites request.
JavaScript Lightbox (iFrame)Upon receipt of the request from the host website the consumer is shown a JavaScript lightbox which contains the payment form within an iFrame, the host website is visible in the background (but shaded). The consumer will enter their card data on this lightbox and request authorisation.

Once complete the consumer will be shown the result and then returned to the applicable URL (depending on result) from the host websites request.
JavaScript Lightbox (Merchant Hosted)Upon receipt of the request from the host website the consumer is shown a JavaScript lightbox which contains the payment form (with the content hosted on the merchant site), the host website is visible in the background (but shaded). The consumer will enter their card data on this lightbox and request authorisation.

Once complete the consumer will be shown the result and then returned to the applicable URL (depending on result) from the host websites request.

The three methods are very similar in terms of implementation on the host website but do have small differences which are detailed in this section.

4.3.1. Choose Scope

The first step is to choose which of the below implementations is to be used for the transaction.

4.3.1.1. Full Redirection

On the host website’s ‘Checkout’ page (the button where the consumer is provided with the option to pay) a JS-library link is required to be added with the method window.DNAPayments.openPaymentPage() chosen.

Within the window.DNAPayments.openPaymentPage() method the “Payment Request” parameters need to be supplied.

4.3.1.2. JavaScript Lightbox (iFrame)

On the host website’s ‘Checkout’ page (the button where the consumer is provided with the option to pay) a JS-library link is required to be added with the method window.DNAPayments.openPaymentIframeWidget() chosen.

Within the window.DNAPayments.openPaymentIframeWidget() method the “Payment Request” parameters need to be supplied.

4.3.1.3. JavaScript Lightbox (Hosted Locally)

On the host website’s ‘Checkout’ page (the button where the consumer is provided with the option to pay) a JS-library link is required to be added with the method window.DNAPayments.openPaymentWidget(paymentData) chosen.

Within the window.DNAPayments.openPaymentIframeWidget() method the “Payment Request” parameters need to be supplied.

4.3.1.4. Testing

For test transactions the URL below should be used.

URL: https://test-pay.dnapayments.com/checkout/payment-api.js

4.3.2. Send Payment Request

Once the scope has been chosen the “Payment Request” data needs to be sent.

4.3.2.1 Payment Request
Field NameStateData TypeDescription
invoiceIdMandatoryStringOrder/invoice/transaction/basket number generated by the host website. This ID must be unique for this transaction.

This value must match the value provided during authorisation or the request will be rejected.
backLinkMandatoryURLAddress where the consumer is to be returned following a successful payment.
failureBackLinkMandatoryURLAddress where the consumer is to be returned following an unsuccessful payment.
postLinkMandatoryURLConfirms where axept® Checkout v3 is to send the payment notification (payment result callback) in the event of a successful result.
failurePostLinkOptionalURLConfirms where axept® Checkout v3 is to send the payment notification (payment result callback) in the event of an unsuccessful result. If not provided the postLink URL will be used.
languageMandatoryStringConsumer language - used by axept® Checkout v3 to build the payment form.
  • EN English
descriptionOptionalStringMessage from host website to consumer, displayed on the payment form.
accountIdOptionalStringUnique reference for the store processing the transaction.
phoneOptionalStringConsumer’s contact phone number.
transactionTypeOptionalStringTransaction type being requested. If this field is not supplied the value configured on the platform is used.
  • AUTH Authorisation Only.
  • SALE Authorisation and Settlement.
  • TOKENIZATION Card Token Registration Only.
terminalMandatoryStringProvided to the integrator following the successful creation of a test account.

This value must match the value provided during authorisation or the request will be rejected.
amountMandatoryDecimalTotal amount of the order including decimal places where applicable. ‘Whole’ amounts (e.g. “1”) on a GBP account will be processed as £1.00.

This value must match the value provided during authorisation or the request will be rejected.
currencyMandatoryStringCurrency of the transaction.
  • GBP Pound Sterling
This value must match the value provided during authorisation or the request will be rejected.
accountCountryMandatoryISO 3166-1 (2 Char.)Field required by 3D Secure v2 as part of the Strong Consumer Authentication [SCA]) requirements.

Country consumer resides in.
accountCityMandatoryString
Max 50 Char.
Field required by 3D Secure v2 as part of the Strong Consumer Authentication [SCA]) requirements

City consumer resides in.
accountStreet1MandatoryString
Max 50 Char.
Field required by 3D Secure v2 as part of the Strong Consumer Authentication [SCA]) requirements

Street consumer resides in.
accountEmailMandatoryString
Max 256 Char.
Field required by 3D Secure v2 as part of the Strong Consumer Authentication [SCA]) requirements

Email address provided by consumer as main contact address.
accountFirstNameMandatoryString
Max 32 Char.
Field required by 3D Secure v2 as part of the Strong Consumer Authentication [SCA]) requirements

Consumer’s first name.
accountLastNameMandatoryString
Max 32 Char.
Field required by 3D Secure v2 as part of the Strong Consumer Authentication [SCA]) requirements

Consumer’s surname/last name.
accountPostalCodeMandatoryString
Max 13 Char.
Field required by 3D Secure v2 as part of the Strong Consumer Authentication [SCA]) requirements

Post code for consumer’s given address.
4.3.2.2. Auth
Field NameData TypeDescription
access_tokenStringAccess token provided by the DNA platform for this transaction. The token should be securely stored ready to be used in the transaction request.
expires_inIntegerNumber of seconds from generation until the access_token expires. If the token is not used before this time has passed a new token will need to be requested.
refresh_tokenStringReserved for future use.
scopeStringConfirmation of the scope passed in the authorisation request.
token_typeStringType of token issued
  • Bearer Bearer token
Example: Create Payment Object
window.DNAPayments.openPaymentPage({
invoiceId: "Order123456",
backLink: "https://example.com/success.html",
failureBackLink: "https://example.com/failure.html",
postLink: "https://example.com/update-order",
failurePostLink: "https://example.com/order/759345/fail",
language: "EN",
description: "Order payment",
accountId: "testuser",
phone: "01234567890",
terminal: "TerminalID",
amount: 10,
currency: "GBP",
accountCountry: "GB",
accountCity: "London",
accountStreet1: "14 Tottenham Court Road",
accountEmail: "test@test.com",
accountFirstName: "Paul",
accountLastName: "Smith",
accountPostalCode: "W1T 1JY",
auth: {
"access_token": "qy/ZWj049WHUZj+8i1pUwmYxswo4GXK+Z5",
"expires_in": 7200,
"refresh_token": "",
"scope": "payment integration_seamless",
"token_type": "Bearer"
}
})

Once the request has been made successfully the consumer is redirected, payment form is loaded and provided to the consumer for them to enter their payment details.

4.4. Step Three: Receiving the Payment Result

Following the completion of the transaction the result is communicated back to the host website in one of the following ways.

Successful TransactionResult sent to the URL provided in the postLink field in the transaction request.
Unsuccessful TransactionResult sent to the URL provided in the failurePostLink field is present in the transaction request. If the field was not present the URL in the postLink field is used.

4.4.1. Payment Result

Field NameData TypeDescription
signatureStringSignature generated for the transaction, for more information on this see 4.4.2 Validating the Signature.
idStringUnique transaction ID.
This ID should be stored as it is required for later transaction actions.
amountDecimalTotal amount of the order including decimal places where applicable. ‘Whole’ amounts (e.g. “1”) on a GBP account represents £1.00.
currencyStringCurrency of the transaction.
  • GBP Pound Sterling
invoiceIdStringOrder/invoice/transaction/basket number generated by the host website, as passed in the request.
accountIdStringUnique reference for the store processing the transaction, as passed in the request.
accountIdStringUnique reference for the store processing the transaction, as passed in the request.
accountIdStringUnique reference for the store processing the transaction, as passed in the request.
rrnStringUnique reference allocated by Optomany to the authorisation.
authDateTimeUTCStringDate and time of when the transaction was authorised with the acquirer.
responseCodeStringReturned by the acquirer detailing the result of the transaction. See Appendix C - Response Codes for a full list.
errorCodeIntegerProvides additional detail should an error have occurred with the transaction.
  • 0 No error occurred.
For a list of error codes and their definitions see Appendix A - Error Codes.
successBooleanConfirms whether the transaction has been successful.
  • true Transaction approved.
  • false Transaction not approved.
settledBooleanConfirms whether the transaction has been submitted for overnight settlement.
  • true Transaction settled.
  • false Transaction not settled.
messageStringMessage confirming the processing result of the transaction request.
authCodeStringAuthorisation code issued for the transaction.
avsHouseNumberResultStringConfirms the result of the Address Verification System (AVS) house number check.
  • Not Set House Number check was not requested.
  • Not Checked House Number could not be checked.
  • Matched House Number matched.
  • Not Matched House Number did not match.
  • Partial Match House Number partially matched.
avsPostcodeResultStringConfirms the result of the Address Verification System (AVS) post code check.
  • Not Set Post Code check was not requested.
  • Not Checked Post Code could not be checked.
  • Matched Post Code matched.
  • Not Matched Post Code did not match.
  • Partial Match Post Code partially matched.
cscResultStringConfirms the result of the Card Security Code (CSC) validation check.
  • Not Set CSC check was not requested.
  • Not Checked CSC could not be checked.
  • Matched CSC matched.
  • Not Matched CSC did not match.
payerAuthenticationResultStringResult of the Payer Authentication process provided in the following format “enrolment result/authentication result”.
The possible results are detailed below.
EnrollmentAuthentication
YSuccessful.Successful.
NNot enrolled.Not authenticated.
AAttempted.Attempted.
UUnable to check.Unable to authenticate.
-Not Attempted.Not Attempted.
As an example an enrolled card which has been fully authenticated will be returned as Y/Y
optomanyTerminalIdStringOptomany Terminal ID used when authorising the transaction.
charitableDonationDecimalAmount of any charitable donation awarded by the consumer during the transaction process.
cardExpiryDateStringExpiry date for the card used in the transaction. Provided in the “MM/YY” format.
cardPanStarredStringStarred PAN for the card used in the transaction - for example ************9909.
cardTokenIdStringOptomany Token ID for the card presented.
cardSchemeIdIntegerOptomany Card Scheme ID for the card used in the transaction. See Appendix B - Card Scheme IDs for a full list of card schemes.
cardSchemeNameStringName of the Card scheme for the card used in the transaction.
cardIssuingCountryStringCountry where the card was issued. This information will only be returned when this can be determined.

This information is subject to change and as such we recommend only using this data as a guide.
Example: Payment Result - Successful
{
"signature": "Lmo7VGQUPMVHT/42w9GiaBNeckGmpt+axvrHlHT+i70=",
"id": "a59ee97d-b9e9-4423-a23c-06d6766b6bfe",
"amount": 25.67,
"currency": "GBP",
"invoiceId": "47365-3556",
"accountId": "32425",
"rrn": "8653/188/11052020143247000",
"authDateTimeUTC": "2020-05-11T16:33:05Z",
"responseCode": "00",
"errorCode": 0,
"success": true,
"settled": true,
"message": "Authorised and settled",
"authCode": "123ABC",
"avsHouseNumberResult": "Partial Match",
"avsPostcodeResult": "Partial Match",
"cscResult": "Matched",
"payerAuthenticationResult": "U/-",
"optomanyTerminalId": "31292612",
"charitableDonation": 0.2,
"cardExpiryDate": "09/20",
"cardPanStarred": "************9909",
"cardTokenId": "XZXIx6WNM+vyvTFBOlGObOZazHurxVN6Sgjxq+CYhVcfMQ==",
"cardSchemeId": 8,
"cardSchemeName": "MasterCard",
"cardIssuingCountry": "Brazil"
}
Example: Payment Result - Unsuccessful
{
"signature": "CjWR0PpiW6dHDdMFr2LYGnPc3kaLtc/cN09ub8+ZFP4=",
"id": "a59ee97d-b9e9-4423-a23c-06d6766b6bfe",
"amount": 25.67,
"currency": "GBP",
"invoiceId": "47365-3556",
"accountId": "32425",
"rrn": "8653/188/11052020143247000",
"authDateTimeUTC": "2020-05-11T16:33:05Z",
"responseCode": "00",
"errorCode": 3010,
"success": false,
"settled": false,
"message": "Transaction Rejected due to AVS",
"authCode": "123ABC",
"avsHouseNumberResult": "Partial Match",
"avsPostcodeResult": "Partial Match",
"cscResult": "Matched",
"payerAuthenticationResult": "U/-",
"optomanyTerminalId": "31292612",
"charitableDonation": 0,
"cardExpiryDate": "09/20",
"cardPanStarred": "************9909",
"cardTokenId": "XZXIx6WNM+vyvTFBOlGObOZazHurxVN6Sgjxq+CYhVcfMQ==",
"cardSchemeId": 8,
"cardSchemeName": "MasterCard",
"cardIssuingCountry": "Brazil"
}

4.4.2. Validating the Signature

To provide integrators with confidence that the transaction response is genuine, a “signature” value is provided within each response message. By performing a simple calculation using the data in the request integrators can verify that the message is valid.

The mechanism for such a check is shown below.

Step No.Details
Step 1Concatenate the below values from the response, in this order.
  • Id
  • amount
  • currency
  • invoiceId
  • errorcode
  • success
Step 2Use a hash function with the “client_secret” acting as the key. See an example below.
Step 3Encode the sum of the hash to base 64. See an example below.
Step 4Verify that the resultant value matches that contained within the request. If it does the transaction can be accepted, if not the message is not genuine and should be disregarded.
Example: Step 2
hash :=hmac.New(sha256.New, secret)
hash.Write(message)
Example: Step 3
Signature = base64.StdEncoding.EncodeToString(hash.Sum(nil))

4.5. Step Four: Redirection to Host

Once the consumer has seen the result of the transaction and is happy to continue, they are invited to press the “Close” button on the payment form. The consumer is then redirected to an address provided in the request from the host website, namely one of the two below.

Successful TransactionURL provided in the payment request field `backLink`
Unsuccessful TransactionURL provided in the payment request field `failureBackLink`

One the consumer is returned to the host website the result can be confirmed and other details such as delivery information etc. can be displayed.

5. Transaction Management

To provide integrators with maximum flexibility when using the axept® Checkout v3 solution several transaction functions can be requested after the transaction has been completed. These functions do not rely on the consumer being present as all consumer interaction has been completed at this point.

Other than the Authentication Request all functions require the “id” (the unique transaction ID generated returned in the Payment Result message) to be present as a minimum.

5.1. Authentication

Authentication with the Transaction Management API is the same as covered in 4.2 Step One: Authentication of this document but with the “scope” set to “webapi”.

Method:POST
Request Body Format:form-data

URL: https://test-oauth.dnapayments.com/oauth2/token

5.1.1. Examples

Example: Authentication Request
Scope=webapi
client_id=Test Merchant
client_secret=PoF84JqIG8Smv5VpES9bcU31kmfSqLk8Jdo7
grant_type=client_credentials
Example: Authentication Response
{
"access_token": "Ez.FCzTxL98J9_weYJBXR5$Ly*bUZg=ScLgh2A4YC5FXeH8RVV2n7EQvA4UXnv7O",
"expires_in": "604800",
"refresh_token": "vNL5bsOusdx.Un-gnlPp9DdseKZW1vI*9mLld=*0P4lYp-IhQZsDFJjKJBo7VXCB",
"scope": "webapi",
"token_type": "Bearer"
}

5.2. Transaction Retrieval

Transaction Retrieval allows the integrator to establish the status of any transaction processed via the axept® Checkout v3 solution.

5.2.1. Request

Method:GET

URL: https://test-api.dnapayments.com/transaction/:id/search

“:id” is the Id of the transaction whose status is required.

5.2.2. Response

Transaction Retrieval Response
Field NameData TypeDescription
idStringUnique transaction ID.

This ID should be stored as it is required for later transaction actions.
amountDecimalTotal amount of the order including decimal places where applicable. ‘Whole’ amounts (e.g. “1”) on a GBP account represents £1.00.
currencyStringCurrency of the transaction.
  • GBP Pound Sterling
invoiceIdStringOrder/invoice/transaction/basket number generated by the host website, as passed in the request.
accountIdStringUnique reference for the store processing the transaction, as passed in the request.
rrnStringUnique reference allocated by Optomany to the authorisation.
authDateTimeUTCStringDate and time of when the transaction was authorised with the acquirer.
responseCodeStringReturned by the acquirer detailing the result of the transaction. See Appendix C - Response Codes for a full list of the response codes.
authCodeStringAuthorisation code issued for the transaction.
avsHouseNumberResultStringConfirms the result of the Address Verification System (AVS) house number check.
  • Not Set House Number check was not requested.
  • Not Checked House Number could not be checked.
  • Matched House Number matched.
  • Not Matched House Number did not match.
  • Partial Match House Number partially matched.
avsPostcodeResultStringConfirms the result of the Address Verification System (AVS) post code check.
  • Not Set Post Code check was not requested.
  • Not Checked Post Code could not be checked.
  • Matched Post Code matched.
  • Not Matched Post Code did not match.
  • Partial Match Post Code partially matched.
cscResultStringConfirms the result of the Card Security Code (CSC) validation check.
  • Not Set CSC check was not requested.
  • Not Checked CSC could not be checked.
  • Matched CSC matched.
  • Not Matched CSC did not match.
payerAuthenticationResultStringResult of the Payer Authentication process provided in the following format “enrolment result/authentication result”.
The possible results are detailed below.
EnrollmentAuthentication
YSuccessful.Successful.
NNot enrolled.Not authenticated.
AAttempted.Attempted.
UUnable to check.Unable to authenticate.
-Not Attempted.Not Attempted.
optomanyTerminalIdStringOptomany Terminal ID used when authorising the transaction.
charitableDonationDecimalAmount of any charitable donation awarded by the consumer during the transaction process.
cardExpiryDateStringExpiry date for the card used in the transaction. Provided in the “MM/YY” format.
cardPanStarredStringStarred PAN for the card used in the transaction - for example ************9909.
cardTokenIdStringOptomany Token ID for the card presented.
cardSchemeIdIntegerOptomany Card Scheme ID for the card used in the transaction. See Appendix B - Card Scheme IDs for a full list of card schemes.
cardSchemeNameStringName of the Card scheme for the card used in the transaction.
cardIssuingCountryStringCountry where the card was issued. This information will only be returned when this can be determined.
This information is subject to change and as such we recommend only using this data as a guide.
stateStringThe current state of the transaction.
  • NEW Transaction created; processing not started.
  • 3D Transaction is currently undergoing Payer Auth.
  • AUTH Transaction is authorised.
  • FAILED Transaction rejected due to an error.
  • REJECT Transaction rejected by acquirer/issuer.
  • CHARGE Transaction settled.
  • CANCEL Transaction reversed.
  • REFUND Transaction refunded.
transactionTypeStringType of transaction.
  • SALE Sale.
  • AUTH Authorisation only.
  • TOKENIZATION Token registration request.
  • RECURRING For future use only.
  • P2P For future use only.

5.2.3. Examples

Example: Request
https://test-api.dnapayments.com/transaction/6fce7714-6109-40d8-b408-0c6700509b6a/search
Accept: application/json
Authorization: Bearer 7KlGv*jFigCc3eReLY1h0yI8O31ZgqITFqyUH6om5w=Vjan=SYnUgeiLQp*_b-c3
Example: Transaction Retrieval Response
{
"accountId": "uuid000001",
"amount": 42.01,
"authCode": "123ABC",
"authDateTimeUTC": "2020-05-18T12:28:02.830039572Z",
"avsHouseNumberResult": "Matched",
"avsPostcodeResult": "Not Matched",
"cardExpiryDate": "06/20",
"cardIssuingCountry": "Brazil",
"cardPanStarred": "************9909",
"cardSchemeId": 8,
"cardSchemeName": "MasterCard",
"cardTokenId": "XZXIx6WNM+vyvTFBOlGObOZazHurxVN6Sgjxq+CYhVcfMQ==",
"cscResult": "Not Matched",
"currency": "GBP",
"id": "6fce7714-6109-40d8-b408-0c6700509b6a",
"invoiceId": "1589804887471",
"optomanyTerminalId": "31292612",
"payerAuthenticationResult": "Y/A",
"payoutAmount": 42.01,
"responseCode": "00",
"rrn": "8653/254/18052020122802000",
"state": "REFUND",
"transactionType": "SALE"
}
Example: Transaction Retrieval Response (Unsuccessful)
{
"code": 2048,
"message": "Transaction cannot be found. Please check input"
}

5.3. Transaction Settlement

note

Transaction Settlement can only be performed when a transaction has been completed as an authorisation only and is in a AUTH state. In this state the funds have been reserved but not yet sent for settlement. Any attempts to perform settlement on a transaction not in this state will be rejected.

The Transaction Settlement is usually utilised by merchants who wish to authorise when the consumer is present on axept® Checkout v3 but only charge when the goods are shipped. This allows for the final amount charged to the consumer to accurately reflect the value of goods that have been sent to them. This is seen as a preferential process than charging the customer the full amount up front and then having to perform a refund using the token Id as a separate transaction.

Transactions can only be charged/sent for settlement successfully once.

5.3.1. Request

Method:POST

URL: https://test-api.dnapayments.com/transaction/operation/charge

Field NameStateData TypeDescription
idMandatoryStringId of the transaction that needs to be charged/sent for settlement.
amountOptionalDecimalValue of transaction to charge. This value cannot be higher than the original authorisation amount. If not supplied the full amount will be charged.

5.3.2. Response

Field NameData TypeDescription
accountIdStringUnique reference for the store processing the transaction.
amountDecimalTotal amount of the original order/authorisation including decimal places where applicable.
currencyStringCurrency of the transaction.
  • GBP Pound Sterling
idStringUnique transaction ID.
invoiceIdStringOrder/invoice/transaction/basket number generated by the host website, as passed in the request.
messageStringMessage confirming the processing result of the transaction request.
payoutAmountDecimalConfirmation of the charge/settlement amount.
successBooleanConfirmation of the charge/settlement result.
  • true Charge/settlement completed successfully.
  • false Charge/settlement not completed successfully.
transactionStateStringThe current state of the transaction.
  • AUTH Transaction is authorised.
  • FAILED Transaction rejected due to an error.
  • REJECT Transaction rejected by acquirer/issuer.
  • CHARGE Transaction settled.
note

Authorisation codes issued during the authorisation process have a limited lifespan. Unfortunately, there are no clear rules as to the validity period, but this is typically anything between three and ten days depending on the card issuer. There is also no way for the validity to be checked.

It is recommended that if there is expected to be a significant delay in the charge process a Transaction Reversal is performed against the original authorisation and the transaction processed when the goods are available using the token Id gained in the initial transaction.

To discuss this further please contact Optomany.

5.3.3. Examples

Example: Transaction Settlement Request
https://test-api.dnapayments.com/transaction/operation/charge
Accept: application/json
Content-Type: application/json
Authorization: Bearer 7KlGv*jFigCc3eReLY1h0yI8O31ZgqITFqyUH6om5w=Vjan=SYnUgeiLQp*_b-c3

{
"id": "6fce7714-6109-40d8-b408-0c6700509b6a",
"amount": 10.00,
}
Example: Transaction Settlement Response (Successful)
{
"accountId": "uuid000001",
"amount": 10.00,
"currency": "GBP",
"id": "6fce7714-6109-40d8-b408-0c6700509b6a",
"invoiceId": "1589804887471",
"message": "Successfully Charged",
"payoutAmount": "10.00",
"success": true,
"state": "CHARGE",
}
Example: Transaction Settlement Response (Unsuccessful)
{
"code": 2038,
"message": “Incorrect Transaction state to perform operation. Please check input”,
"success": false,
}

5.4. Transaction Reversal

note

Transaction Reversal can only be performed when a transaction has been completed as an authorisation only and is in an AUTH state. In this state the funds have been reserved but not yet sent for settlement. Any attempts to perform settlement on a transaction not in this state will be rejected.

The Transaction Reversal function is a companion to the Transaction Settlement request, in that it is also used for merchants who wish to manage their transactions as a two-step process. Where the Transaction Settlement request allows the merchant to complete the transaction and claim the funds the Transaction Reversal request allows the merchant to cancel the authorisation in place and return the available balance to the consumers card.

This is most likely to be used in scenarios where the merchant has discovered that they are unable to fulfil the order as planned, for example when items ordered have gone permanently out of stock.

Authorisation codes issued but not charged/settled will automatically expire but it is best practise behaviour to reverse where possible - thus giving the consumer back the amount into their available balance sooner.

5.4.1. Request

Method:POST

URL: https://test-api.dnapayments.com/transaction/operation/cancel

Field NameStateData TypeDescription
idMandatoryStringId of the transaction that needs to be reversed.

5.4.2. Response

Field NameData TypeDescription
accountIdStringUnique reference for the store processing the transaction.
amountDecimalTotal amount of the original order/authorisation including decimal places where applicable.
currencyStringCurrency of the transaction.
  • GBP Pound Sterling
idStringUnique transaction ID.
invoiceIdStringOrder/invoice/transaction/basket number generated by the host website, as passed in the request.
messageStringMessage confirming the processing result of the transaction request.
payoutAmountDecimalConfirmation of the reversal amount.
successBooleanConfirmation of the reversal result.
  • true Reversal completed successfully.
  • false Reversal not completed successfully.
transactionStateStringThe current state of the transaction.
  • AUTH Transaction is authorised.
  • FAILED Transaction rejected due to an error.
  • REJECT Transaction rejected by acquirer/issuer.
  • CHARGE Transaction settled.
note

Upon receipt of the Transaction Reversal request axept® Checkout v3 will attempt to perform a reversal with the merchant’s acquirer. Whilst these are often successful there is a chance that the reversal cannot be completed for specific transactions, this is something that is beyond Optomany’s control.

5.4.3. Examples

Example: Transaction Reversal
{
"id": "6fce7714-6109-40d8-b408-0c6700509b6a",
}
Example: Transaction Reversal Response (Successful)
{
"accountId": "uuid000001",
"amount": 10.00,
"currency": "GBP",
"id": "6fce7714-6109-40d8-b408-0c6700509b6a",
"invoiceId": "1589804887471",
"message": "Successfully Cancelled",
"payoutAmount": "10.00",
"success": true,
"state": "CANCEL",
}
Example: Transaction Reversal Response (Unsuccessful)
{
"code": 2068,
"message": “Requested amount is not valid”,
"success": false,
}

5.5. Transaction Refund

note

Transaction Refund can only be performed when a transaction has been charged/settled and is in a “CHARGE” state. Any transaction which is not yet settled/charged should be cancelled via the Transaction Reversal function.

Merchant’s will encounter scenario where they are required to refund a consumer, either for the full transaction amount (in the case of a return of goods) or in some cases for a reduced amount (such as a gesture of goodwill for issues experienced). axept® Checkout v3 allows merchants to manage this themselves using the token Id and the axept® Gateway solution, but this requires the additional integration to be completed.

To simplify the process axept® Checkout v3 has introduced the ability for a merchant to perform a refund against the transaction Id, removing the requirement to even store the consumers token id. The refund request can be for any value up to the value of the original transaction. Only one refund can be processed against each Id and therefore if additional refunds are required to be made these will have to be completed using the token via the axept® Gateway.

5.5.1. Request

Method:POST

URL: https://test-api.dnapayments.com/transaction/operation/refund

Field NameStateData TypeDescription
idMandatoryStringId of the transaction that needs to be refunded.
amountOptionalDecimalValue of transaction to refund. This value cannot be higher than the original authorisation amount. If not supplied the full refund will be processed.

5.5.2. Response

Field NameData TypeDescription
accountIdStringUnique reference for the store processing the transaction.
amountDecimalTotal amount of the original order/authorisation including decimal places where applicable.
currencyStringCurrency of the transaction.
  • GBP Pound Sterling
idStringUnique transaction ID.
invoiceIdStringOrder/invoice/transaction/basket number generated by the host website, as passed in the request.
messageStringMessage confirming the processing result of the transaction request.
payoutAmountDecimalConfirmation of the refund amount.
successBooleanConfirmation of the refund result.
  • true Refund completed successfully.
  • false Refund not completed successfully.
transactionStateStringThe current state of the transaction.
  • AUTH Transaction is authorised.
  • FAILED Transaction rejected due to an error.
  • REJECT Transaction rejected by acquirer/issuer.
  • CHARGE Transaction settled.

5.5.3. Examples

Example: Transaction Refund Request
{
"id": "6fce7714-6109-40d8-b408-0c6700509b6b",
"amount": 9.99,
}
Example: Transaction Refund Response (Successful)
{
"accountId": "uuid000002",
"amount": 9.99,
"currency": "GBP",
"id": "6fce7714-6109-40d8-b408-0c6700509b6b",
"invoiceId": "1589804887472",
"message": "Successfully Refunded",
"payoutAmount": "9.99",
"success": true,
"state": "REFUND",
}
Example: Transaction Refund Response (Unsuccessful)
{
"code": 2038,
"message": “Incorrect Transaction state to perform operation. Please check input”,
"success": false,
}

6. Reporting Portal

The axept® Checkout v3 solution is backed by a powerful merchant portal which allows merchants to view custom dashboards and view detailed transaction information.

The portal can be accessed at https://mp.dnapayments.com

A user login is created for integrators whilst the test account was configured, however if this is not the case please contact the Optomany Product Delivery team and request one using the contact details at the end of this document.

PHOTO

7. Integration Approval

This section provides information on Integration Approval, a process which needs to be completed by all integrators prior to their website going live.

7.1. What is ‘Integration Approval’?

As axept® Checkout v3 is generically approved by the Acquirers, the responsibility for ensuring that partners integration meets the required standard lies with Optomany. Therefore prior to any partner or end user integration processing live transactions, they must first be certified in an integration approval by one of Optomany’s Solution Consultants.

A test script has been created to cover all processing scenarios whilst not featuring a large number of repetition as is the case in some test processes carried out within the industry. The overall aim of the process is to ensure that the website integration can correctly process all supported transaction types and handle the various error conditions that can occur. This is especially important as the correct handling of these scenarios make sure that the use of the website is as trouble free as possible.

7.2. How Is the Approval Completed?

To verify that the integration has been completed correctly, a brief test needs to be completed. This testing is completed remotely by an Optomany Solutions Consultant. The integrator/merchant needs to provide access to a copy of the website (as it will be when live) which is pointing to the Optomany Test Managed Service. Typically, this site is already available as it has been used for internal/UAT testing by the merchant.

7.3. What Happens If I Make a Change After Approval?

It is understood that integrated solutions are updated in the same way as axept® Checkout v3 is updated when new functionality becomes available. It would be completely impractical for Optomany to request a re-test to be performed every time an update is made, and this is not what is required.

When an amendment is made, Optomany only need to be informed if changes are being made to the payment processing code. Optomany recommend that merchants/integrators contact the Product Delivery team in the event of any changes to the code responsible for the integration to axept® Checkout v3 where the testing requirements (if any) can be discussed.

7.4. Before Booking an Integration Approval

Before contacting Optomany to arrange an integration approval, it is recommended that a full run through of the test script is completed, this will ensure that the integration passes all requirements. Completing this beforehand removes the possibility of a wasted test session and the associated delays in getting the website live.

7.5. How to Book an Integration Test

Once the test script has been run and all tests passed, please contact Optomany using the contact details at the end of this document.

Once the email has been received, a Solutions Consultant will be in contact with regards to scheduling the test session.

7.6. What Happens After Integration Approval?

Once the integration testing is complete, the Solutions Consultant will confirm whether the tests have been passed. If there have been some failures, time will be allowed for amendments to be made and the tests re-attempted. However, should these fixes not be possible or that there is not sufficient time remaining, a new test session will need to be booked.

If the testing is passed, confirmation of this will be provided on the day. This means that the integrated solution can be rolled live in (its tested form) straight away. Documentation confirming the result will be sent to the named contact within two weeks of the successful test.

Details of the solution tested will also be stored internally at Optomany allowing us to ensure that only approved integrations are set live.

8. Contact Information

Optomany’s Product Delivery team are solution experts and on hand to support you through the integration process, from initial account setup through to the integration testing process and go-live. Should you experience an issue during testing please ensure that, where applicable, you have the transaction Id or authorisation token available for the team.

If you have any questions or require support, please get in touch with us using the details below:

Optomany Product Delivery

Phone:+44 (0) 20 8102 8000
Email:integration@dnapaymentsgroup.com

Product Delivery Hours

Days:Monday - Friday
Hours Covered:09:00 – 17:30

Appendix A - Error Codes

CodeDescriptionGuidance
0No error occurred - process completed successfullyNo further action needed
86UnauthorizedCheck authentication token
87No valid token providedCheck authentication token
1000Required Field Validation ErrorCheck request and amend
1001Cannot decrypt cryptogram*With DNA* Cryptogram is used between the payment page and back-end. Problem with a certificate, need to communicate with us.
1002Cannot unmarshal cryptogram data*With DNA* Cryptogram is used between the payment page and back-end. Problem with a certificate, need to communicate with us.
1003Cannot marshal request*With DNA* Cryptogram is used between the payment page and back-end. Problem with a certificate, need to communicate with us.
1004Payment gateway error*With DNA* Try again. This occur when we cannot get or decode the response.
1005Operation not permittedPlease check your authorisation scope
1006Input Field Value Validation Error: amount cannot be interpreted as a float64Check and amend amount
1007Requested Amount is not validCheck and amend amount
1008Field amount cannot be foundCheck and amend amount
1009Input Field Value Validation Error: parentTransactionid cannot be interpreted as a stringCheck and amend parentTransactionId
1010Input Field Value Validation Error: parentTransactionid cannot be interpreted as a UUIDCheck and amend parentTransactionId
1011Input Field Value Validation Error: parentTransactionid cannot be foundCheck and amend parentTransactionId
1012Input Field Value Validation Error: transactionType cannot be interpreted as a stringCheck and amend transactionType
1013Input Field Value Validation Error: Requested transactionType not supportedCheck and amend transactionType
1014Input Field Value Validation Error: transactionType cannot be foundCheck and amend transactionType
1015Input Field Value Validation Error: sequenceType cannot be interpreted as a stringCheck and amend sequenceType
1016Input Field Value Validation Error: Requested sequenceType not supportedCheck and amend sequenceType
1017Input Field Value Validation Error: sequenceType cannot be foundCheck and amend sequenceType
1018Input Field Value Validation Error: periodicType cannot be interpreted as a stringCheck and amend periodicType
1019Input Field Value Validation Error: Requested periodicType not supportedCheck and amend periodicType
1020Input Field Value Validation Error: sequenceType cannot be foundCheck and amend sequenceType
1021A valid Transaction ID is requiredCheck and amend Transaction Id
1022Required Field Validation ErrorCheck fields in request, amend and retry
1023Transaction Unsuccessful due to Processing IssueRetry - if issue continues please contact Optomany
1024Transaction Unsuccessful due to Processing IssueRetry - if issue continues please contact Optomany
1025Required Field Validation ErrorCheck fields in request, amend and retry
1026Input Field Value Validation Error: amount cannot be interpreted as a float64Check and amend amount
1027Requested Amount is not validCheck and amend amount
1028Input Field Value Validation Error: id cannot be interpreted as a string or UUIDCheck and amend id
1029Input Field Value Validation Error: id cannot be foundCheck and amend id
1030Input Field Value Validation Error: reason cannot be interpreted as a stringCheck and amend reason
1031A valid Transaction ID is requiredCheck and amend Transaction Id
1032Required Field Validation ErrorCheck fields in request, amend and retry
1033Transaction Unsuccessful due to Processing IssueRetry - if issue continues please contact Optomany
1034Transaction Unsuccessful due to Processing IssueRetry - if issue continues please contact Optomany
1035Operation not permitted. Please check your authorisation scopePlease check your authorisation scope
1036Cannot retrieve transaction due to system issueRetry - if issue continues please contact Optomany
1037Cannot decode 3D Secure response*With DNA* Retry - if issue continues please contact Optomany
1038Cannot decode 3D Secure response*With DNA* Retry - if issue continues please contact Optomany
1039Cannot decode gateway response*With DNA* Retry - if issue continues please contact Optomany
1040Transaction rejected due to system issue*With DNA* Change this description
2001Error binding JSON*With DNA* Check and amend request format
2002Invalid currency codeCheck and amend currency code
2003A mandatory field or the value of the token fields (invoiceId, amount, currency, terminal) does not match the format expectedCheck and amend token fields
2004Invalid TokenCheck and amend token fields
2005The value of a field invoiceId does not match the tokenCheck and amend invoiceId
2006The value of a field terminalId does not match the tokenCheck and amend terminalId
2007The value of a field currency does not match the tokenCheck and amend currency
2008The value of a field amount does not match the tokenCheck and amend amount
2009The value of a field amount cannot be interpreted as float64Check and amend amount
2010Provided terminalId not foundCheck and amend terminalId
2011The value of a field terminalId cannot be matched with the Merchant IDCheck and amend terminalId
2012Merchant is not activeContact Optomany
2013Terminal limit exceededContact Optomany
2014Terminal limit exceededContact Optomany
2015Terminal limit exceededContact Optomany
2016Terminal limit exceededContact Optomany
2017Transaction check error*With DNA* Transaction duplicating check cannot be performed
2018Duplicate Transaction – This transaction ('invoiceId') has already been acceptedDuplicate transaction has been prevented
2020Unable to create transaction due to technical issuesRetry - if issue continues please contact Optomany
2021Unable to save transaction parameters due to technical issuesRetry - if issue continues please contact Optomany
2022Transaction Unsuccessful due to Processing IssueRetry - if issue continues please contact Optomany
2023Transaction Unsuccessful due to Processing IssueRetry - if issue continues please contact Optomany
2024Transaction Unsuccessful due to Processing IssueRetry - if issue continues please contact Optomany
2025Transaction UnsuccessfulRetry - if issue continues please contact Optomany
2026Cannot unmarshal 3D Secure parametersRetry - if issue continues please contact Optomany
2027Cannot get 3D Secure parametersRetry - if issue continues please contact Optomany
2028Cannot save TransactionRetry - if issue continues please contact Optomany
2029Transaction DeclinedDeclined by the acquirer/issuer
2030Cannot save TransactionRetry - if issue continues please contact Optomany
2031Cannot save TransactionRetry - if issue continues please contact Optomany
2036Cannot bind the ACS responseRetry - if issue continues please contact Optomany
2037Cannot find the transactionCheck details and retry
2038Incorrect Transaction state to perform operationCheck transaction state
2039Incorrect 3D Secure 'MD' data to perform operation*With DNA* The ACS response was somehow changed
2040Transaction Unsuccessful due to Processing IssueRetry - if issue continues please contact Optomany
2041Cannot save TransactionRetry - if issue continues please contact Optomany
2042Transaction Unsuccessful due to Processing IssueRetry - if issue continues please contact Optomany
2043Transaction UnsuccessfulRetry - if issue continues please contact Optomany
2044Transaction DeclinedDeclined by the acquirer/issuer
2045Cannot save TransactionRetry - if issue continues please contact Optomany
2047Transaction cannot be retrieved due to System IssueRetry - if issue continues please contact Optomany
2048Transaction cannot be foundPlease check input data
2049Incorrect Transaction state to perform operationCheck transaction state
2050Requested Amount is not validCheck and amend amount
2051This payment has already been chargedUnable to charge an already charged transaction
2052Operation UnsuccessfulRetry - if issue continues please contact Optomany
2053Operation UnsuccessfulRetry - if issue continues please contact Optomany
2054Operation UnsuccessfulRetry - if issue continues please contact Optomany
2056Error binding JSONRetry - if issue continues please contact Optomany
2057Transaction cannot be retrieved due to System IssueRetry - if issue continues please contact Optomany
2058Transaction cannot be foundPlease check input data
2059Incorrect Transaction state to perform operationPlease check input data
2060Requested Amount is not validCheck and amend amount
2061Operation Unsuccessful due to Processing IssueRetry - if issue continues please contact Optomany
2062Operation Unsuccessful due to Processing IssueRetry - if issue continues please contact Optomany
2063Operation Unsuccessful due to Processing IssueRetry - if issue continues please contact Optomany
2065Cannot bind JSONRetry - if issue continues please contact Optomany
2066Invalid TokenCheck and amend Token
2067Incorrect Transaction state to perform operationCheck transaction state
2068Requested Amount is not validCheck and amend amount
2069Merchant is not validContact Optomany
2070Merchant is not activeContact Optomany
2100Transaction cannot be retrieved due to an authentication issueCheck authentication token
3010Transaction Rejected due to AVSRejected due to AVS matrices - reversed
3011Transaction Rejected due to AVS and CSCRejected due to AVS and CSC matrices - reversed
3012Transaction Rejected due to CSCRejected due to CSC matrices - reversed
3013Transaction Rejected due to AVS but not reversedRejected due to AVS matrices - not reversed
3014Transaction Rejected due to AVS and CSC but not reversedRejected due to AVS and CSC matrices - not reversed
3015Transaction Rejected due to CSC but not reversedRejected due to CSC matrices - not reversed
3016Transaction Unsuccessful - Voice ReferralRejected due to referral response from acquirer/issuer
3017Transaction DeclinedDeclined by acquirer/issuer
3018Transaction Rejected due to 3D SecureRejected due to Payer Authentication matrices

Appendix B - Card Scheme IDs

IDCard SchemeDescription
1AMEXAmerican Express
2AMEX CPCAmerican Express Corporate Purchasing
3DinersDiners
4DiscoverDiscover
5FlexecashFlexecash
6JCBJCB
7MaestroMaestro
8MasterCardMasterCard
9MasterCard OneMasterCard Purchasing/Fleet/Multicard
10MasterCard DEBITDebit MasterCard
11VISAVISA
12VISA ATM OnlyATM Only VISA Card
13VISA CPC (MI Only)UK VISA Purchasing Cards (MI Only)
14VISA CPC (VAT)UK VISA Purchasing Cards (VAT)
15VISA DEBITUK VISA Debit Card
16VISA ElectronUK VISA Electron
17UK MaestroMaestro UK
18UnionPayChina Union Pay
19UnionPay (AMEX)China Union Pay & AMEX Dual Branded Card
20UnionPay (Diners)China Union Pay & Diners Dual Branded Card
21UnionPay (JCB)China Union Pay & JCB Dual Branded Card
22UnionPay (Maestro)China Union Pay & Maestro Dual Branded Card
23UnionPay (MasterCard)China Union Pay & MasterCard Dual Branded Card
24UnionPay (VISA)China Union Pay and VISA Dual Branded Card
25VISA PurchasingVISA Purchasing
26Reserved for Optomany UseReserved for Optomany Use
27Reserved for Optomany UseReserved for Optomany Use
28Reserved for Optomany UseReserved for Optomany Use

Appendix C - Response Codes

CodeDescription
00Approval
02Referral
03Denial
05Denial
21Denial
30Denial
55Denial
63Denial
85Approval
96Denial
98Denial
99Denial
Y1Offline Acceptance