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
	Visa Credit
	Visa Debit
	Mastercard Credit
	Mastercard Debit
	Maestro
	American Express
	Diners/Discover

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

Payer Authentication Scheme		Card Scheme
	Verified by VISA (VBV)	VISA Credit & VISA Debit Cards
	MasterCard SecureCode	MasterCard Credit, MasterCard Debit and Maestro Cards
	American Express Safekey	American 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

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

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 Name	State	Data Type	Description
grant_type	Mandatory	String	Authorisation type required to confirm the action required. client_credentials Obtain credentials required to process a transaction.
scope	Mandatory	String	Confirm 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_id	Mandatory	String	Provided to the integrator following the successful creation of a test account.
client_secret	Mandatory	String	Provided to the integrator following the successful creation of a test account.
invoiceId	Mandatory	String	Order/invoice/transaction/basket number generated by the host website. This ID must be unique for this transaction.
amount	Mandatory	Decimal	Total amount of the order including decimal places where applicable. ‘Whole’ amounts (e.g. “1”) on a GBP account will be processed as £1.00.
currency	Mandatory	String	Currency of the transaction. GBP Pound Sterling
terminal	Mandatory	String	Provided to the integrator following the successful creation of a test account.
postLink	Optional	URL	Must be a fully qualified URL. If provided this data is used for extra checking when the transaction request is received.
failurePostLink	Optional	URL	Must 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 Name	Data Type	Description
access_token	String	Access token provided by the DNA platform for this transaction. The token should be securely stored ready to be used in the transaction request.
expires_in	Integer	Number 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_token	String	Reserved for future use.
scope	String	Confirmation of the scope(s) passed in the authorisation request.
token_type	String	Type 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 Redirect	The 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.

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 Name	State	Data Type	Description
invoiceId	Mandatory	String	Order/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.
backLink	Mandatory	URL	Address where the consumer is to be returned following a successful payment.
failureBackLink	Mandatory	URL	Address where the consumer is to be returned following an unsuccessful payment.
postLink	Mandatory	URL	Confirms where axept® Checkout v3 is to send the payment notification (payment result callback) in the event of a successful result.
failurePostLink	Optional	URL	Confirms 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.
language	Mandatory	String	Consumer language - used by axept® Checkout v3 to build the payment form. EN English
description	Optional	String	Message from host website to consumer, displayed on the payment form.
accountId	Optional	String	Unique reference for the store processing the transaction.
phone	Optional	String	Consumer’s contact phone number.
transactionType	Optional	String	Transaction 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.
terminal	Mandatory	String	Provided 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.
amount	Mandatory	Decimal	Total 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.
currency	Mandatory	String	Currency of the transaction. GBP Pound Sterling This value must match the value provided during authorisation or the request will be rejected.
accountCountry	Mandatory	ISO 3166-1 (2 Char.)	Field required by 3D Secure v2 as part of the Strong Consumer Authentication [SCA]) requirements. Country consumer resides in.
accountCity	Mandatory	String Max 50 Char.	Field required by 3D Secure v2 as part of the Strong Consumer Authentication [SCA]) requirements City consumer resides in.
accountStreet1	Mandatory	String Max 50 Char.	Field required by 3D Secure v2 as part of the Strong Consumer Authentication [SCA]) requirements Street consumer resides in.
accountEmail	Mandatory	String 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.
accountFirstName	Mandatory	String Max 32 Char.	Field required by 3D Secure v2 as part of the Strong Consumer Authentication [SCA]) requirements Consumer’s first name.
accountLastName	Mandatory	String Max 32 Char.	Field required by 3D Secure v2 as part of the Strong Consumer Authentication [SCA]) requirements Consumer’s surname/last name.
accountPostalCode	Mandatory	String 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 Name	Data Type	Description
access_token	String	Access token provided by the DNA platform for this transaction. The token should be securely stored ready to be used in the transaction request.
expires_in	Integer	Number 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_token	String	Reserved for future use.
scope	String	Confirmation of the scope passed in the authorisation request.
token_type	String	Type 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 Transaction	Result sent to the URL provided in the postLink field in the transaction request.
Unsuccessful Transaction	Result 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 Name

Data Type

Description

signature

String

Signature generated for the transaction, for more information on this see 4.4.2 Validating the Signature.

String

Unique transaction ID.
This ID should be stored as it is required for later transaction actions.

amount

Decimal

Total amount of the order including decimal places where applicable. ‘Whole’ amounts (e.g. “1”) on a GBP account represents £1.00.

currency

String

Currency of the transaction.

GBP Pound Sterling

invoiceId

String

Order/invoice/transaction/basket number generated by the host website, as passed in the request.

accountId

String

Unique reference for the store processing the transaction, as passed in the request.

accountId

String

Unique reference for the store processing the transaction, as passed in the request.

accountId

String

Unique reference for the store processing the transaction, as passed in the request.

rrn

String

Unique reference allocated by Optomany to the authorisation.

authDateTimeUTC

String

Date and time of when the transaction was authorised with the acquirer.

responseCode

String

Returned by the acquirer detailing the result of the transaction. See Appendix C - Response Codes for a full list.

errorCode

Integer

Provides 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.

success

Boolean

Confirms whether the transaction has been successful.

true Transaction approved.
false Transaction not approved.

settled

Boolean

Confirms whether the transaction has been submitted for overnight settlement.

true Transaction settled.
false Transaction not settled.

message

String

Message confirming the processing result of the transaction request.

authCode

String

Authorisation code issued for the transaction.

avsHouseNumberResult

String

Confirms 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.

avsPostcodeResult

String

Confirms 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.

cscResult

String

Confirms 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.

payerAuthenticationResult

String

Result of the Payer Authentication process provided in the following format “enrolment result/authentication result”.
The possible results are detailed below.

	Enrollment	Authentication
Y	Successful.	Successful.
N	Not enrolled.	Not authenticated.
A	Attempted.	Attempted.
U	Unable 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

optomanyTerminalId

String

Optomany Terminal ID used when authorising the transaction.

charitableDonation

Decimal

Amount of any charitable donation awarded by the consumer during the transaction process.

cardExpiryDate

String

Expiry date for the card used in the transaction. Provided in the “MM/YY” format.

cardPanStarred

String

Starred PAN for the card used in the transaction - for example ************9909.

cardTokenId

String

Optomany Token ID for the card presented.

cardSchemeId

Integer

Optomany Card Scheme ID for the card used in the transaction. See Appendix B - Card Scheme IDs for a full list of card schemes.

cardSchemeName

String

Name of the Card scheme for the card used in the transaction.

cardIssuingCountry

String

Country 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 1	Concatenate the below values from the response, in this order. Id amount currency invoiceId errorcode success
Step 2	Use a hash function with the “client_secret” acting as the key. See an example below.
Step 3	Encode the sum of the hash to base 64. See an example below.
Step 4	Verify 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 Transaction	URL provided in the payment request field `backLink`
Unsuccessful Transaction	URL 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 Name

Data Type

Description

String

Unique transaction ID.

This ID should be stored as it is required for later transaction actions.

amount

Decimal

Total amount of the order including decimal places where applicable. ‘Whole’ amounts (e.g. “1”) on a GBP account represents £1.00.

currency

String

Currency of the transaction.

GBP Pound Sterling

invoiceId

String

Order/invoice/transaction/basket number generated by the host website, as passed in the request.

accountId

String

Unique reference for the store processing the transaction, as passed in the request.

rrn

String

Unique reference allocated by Optomany to the authorisation.

authDateTimeUTC

String

Date and time of when the transaction was authorised with the acquirer.

responseCode

String

Returned by the acquirer detailing the result of the transaction. See Appendix C - Response Codes for a full list of the response codes.

authCode

String

Authorisation code issued for the transaction.

avsHouseNumberResult

String

Confirms 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.

avsPostcodeResult

String

Confirms 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.

cscResult

String

Confirms 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.

payerAuthenticationResult

String

Result of the Payer Authentication process provided in the following format “enrolment result/authentication result”.
The possible results are detailed below.

	Enrollment	Authentication
Y	Successful.	Successful.
N	Not enrolled.	Not authenticated.
A	Attempted.	Attempted.
U	Unable to check.	Unable to authenticate.
-	Not Attempted.	Not Attempted.

optomanyTerminalId

String

Optomany Terminal ID used when authorising the transaction.

charitableDonation

Decimal

Amount of any charitable donation awarded by the consumer during the transaction process.

cardExpiryDate

String

Expiry date for the card used in the transaction. Provided in the “MM/YY” format.

cardPanStarred

String

Starred PAN for the card used in the transaction - for example ************9909.

cardTokenId

String

Optomany Token ID for the card presented.

cardSchemeId

Integer

Optomany Card Scheme ID for the card used in the transaction. See Appendix B - Card Scheme IDs for a full list of card schemes.

cardSchemeName

String

Name of the Card scheme for the card used in the transaction.

cardIssuingCountry

String

Country 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.

state

String

The 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.

transactionType

String

Type 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 Name	State	Data Type	Description
id	Mandatory	String	Id of the transaction that needs to be charged/sent for settlement.
amount	Optional	Decimal	Value 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 Name	Data Type	Description
accountId	String	Unique reference for the store processing the transaction.
amount	Decimal	Total amount of the original order/authorisation including decimal places where applicable.
currency	String	Currency of the transaction. GBP Pound Sterling
id	String	Unique transaction ID.
invoiceId	String	Order/invoice/transaction/basket number generated by the host website, as passed in the request.
message	String	Message confirming the processing result of the transaction request.
payoutAmount	Decimal	Confirmation of the charge/settlement amount.
success	Boolean	Confirmation of the charge/settlement result. true Charge/settlement completed successfully. false Charge/settlement not completed successfully.
transactionState	String	The 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 Name	State	Data Type	Description
id	Mandatory	String	Id of the transaction that needs to be reversed.

5.4.2. Response

Field Name	Data Type	Description
accountId	String	Unique reference for the store processing the transaction.
amount	Decimal	Total amount of the original order/authorisation including decimal places where applicable.
currency	String	Currency of the transaction. GBP Pound Sterling
id	String	Unique transaction ID.
invoiceId	String	Order/invoice/transaction/basket number generated by the host website, as passed in the request.
message	String	Message confirming the processing result of the transaction request.
payoutAmount	Decimal	Confirmation of the reversal amount.
success	Boolean	Confirmation of the reversal result. true Reversal completed successfully. false Reversal not completed successfully.
transactionState	String	The 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 Name	State	Data Type	Description
id	Mandatory	String	Id of the transaction that needs to be refunded.
amount	Optional	Decimal	Value 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 Name	Data Type	Description
accountId	String	Unique reference for the store processing the transaction.
amount	Decimal	Total amount of the original order/authorisation including decimal places where applicable.
currency	String	Currency of the transaction. GBP Pound Sterling
id	String	Unique transaction ID.
invoiceId	String	Order/invoice/transaction/basket number generated by the host website, as passed in the request.
message	String	Message confirming the processing result of the transaction request.
payoutAmount	Decimal	Confirmation of the refund amount.
success	Boolean	Confirmation of the refund result. true Refund completed successfully. false Refund not completed successfully.
transactionState	String	The 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

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

Appendix B - Card Scheme IDs

ID	Card Scheme	Description
1	AMEX	American Express
2	AMEX CPC	American Express Corporate Purchasing
3	Diners	Diners
4	Discover	Discover
5	Flexecash	Flexecash
6	JCB	JCB
7	Maestro	Maestro
8	MasterCard	MasterCard
9	MasterCard One	MasterCard Purchasing/Fleet/Multicard
10	MasterCard DEBIT	Debit MasterCard
11	VISA	VISA
12	VISA ATM Only	ATM Only VISA Card
13	VISA CPC (MI Only)	UK VISA Purchasing Cards (MI Only)
14	VISA CPC (VAT)	UK VISA Purchasing Cards (VAT)
15	VISA DEBIT	UK VISA Debit Card
16	VISA Electron	UK VISA Electron
17	UK Maestro	Maestro UK
18	UnionPay	China Union Pay
19	UnionPay (AMEX)	China Union Pay & AMEX Dual Branded Card
20	UnionPay (Diners)	China Union Pay & Diners Dual Branded Card
21	UnionPay (JCB)	China Union Pay & JCB Dual Branded Card
22	UnionPay (Maestro)	China Union Pay & Maestro Dual Branded Card
23	UnionPay (MasterCard)	China Union Pay & MasterCard Dual Branded Card
24	UnionPay (VISA)	China Union Pay and VISA Dual Branded Card
25	VISA Purchasing	VISA Purchasing
26	Reserved for Optomany Use	Reserved for Optomany Use
27	Reserved for Optomany Use	Reserved for Optomany Use
28	Reserved for Optomany Use	Reserved for Optomany Use

Appendix C - Response Codes

Code	Description
00	Approval
02	Referral
03	Denial
05	Denial
21	Denial
30	Denial
55	Denial
63	Denial
85	Approval
96	Denial
98	Denial
99	Denial
Y1	Offline Acceptance

1. Welcome​

2. Supported Payment Methods​

3. Before Starting​

4. Integrating to axept® Checkout v3​

4.1. Operation Modes - “scope”​

4.1.1. Full Re-Direct​

4.1.2. JavaScript Lightbox (iFrame)​

4.1.3. JavaScript Lightbox (Locally Hosted)​

4.1.4. Branding​

4.2. Step One: Authentication​

4.2.1. Authentication POST - Request​

4.2.2. Authentication POST - Response​

4.3. Step Two: Redirection for Payment​

4.3.1. Choose Scope​

4.3.1.1. Full Redirection​

4.3.1.2. JavaScript Lightbox (iFrame)​

4.3.1.3. JavaScript Lightbox (Hosted Locally)​

4.3.1.4. Testing​

4.3.2. Send Payment Request​

4.3.2.1 Payment Request​

4.3.2.2. Auth​

4.4. Step Three: Receiving the Payment Result​

4.4.1. Payment Result​

4.4.2. Validating the Signature​

4.5. Step Four: Redirection to Host​

5. Transaction Management​

5.1. Authentication​

5.1.1. Examples​

5.2. Transaction Retrieval​

5.2.1. Request​

5.2.2. Response​

5.2.3. Examples​

5.3. Transaction Settlement​

5.3.1. Request​

5.3.2. Response​

5.3.3. Examples​

5.4. Transaction Reversal​

5.4.1. Request​

5.4.2. Response​

5.4.3. Examples​

5.5. Transaction Refund​

5.5.1. Request​

5.5.2. Response​

5.5.3. Examples​

6. Reporting Portal​

7. Integration Approval​

7.1. What is ‘Integration Approval’?​

7.2. How Is the Approval Completed?​

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

7.4. Before Booking an Integration Approval​

7.5. How to Book an Integration Test​

7.6. What Happens After Integration Approval?​

8. Contact Information​

Appendix A - Error Codes​

Appendix B - Card Scheme IDs​

Appendix C - Response Codes​

1. Welcome

2. Supported Payment Methods

3. Before Starting

4. Integrating to axept® Checkout v3

4.1. Operation Modes - “scope”

4.1.1. Full Re-Direct

4.1.2. JavaScript Lightbox (iFrame)

4.1.3. JavaScript Lightbox (Locally Hosted)

4.1.4. Branding

4.2. Step One: Authentication

4.2.1. Authentication POST - Request

4.2.2. Authentication POST - Response

4.3. Step Two: Redirection for Payment

4.3.1. Choose Scope

4.3.1.1. Full Redirection

4.3.1.2. JavaScript Lightbox (iFrame)

4.3.1.3. JavaScript Lightbox (Hosted Locally)

4.3.1.4. Testing

4.3.2. Send Payment Request

4.3.2.1 Payment Request

4.3.2.2. Auth

4.4. Step Three: Receiving the Payment Result

4.4.1. Payment Result

4.4.2. Validating the Signature

4.5. Step Four: Redirection to Host

5. Transaction Management

5.1. Authentication

5.1.1. Examples

5.2. Transaction Retrieval

5.2.1. Request

5.2.2. Response

5.2.3. Examples

5.3. Transaction Settlement

5.3.1. Request

5.3.2. Response

5.3.3. Examples

5.4. Transaction Reversal

5.4.1. Request

5.4.2. Response

5.4.3. Examples

5.5. Transaction Refund

5.5.1. Request

5.5.2. Response

5.5.3. Examples

6. Reporting Portal

7. Integration Approval

7.1. What is ‘Integration Approval’?

7.2. How Is the Approval Completed?

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

7.4. Before Booking an Integration Approval

7.5. How to Book an Integration Test

7.6. What Happens After Integration Approval?

8. Contact Information

Appendix A - Error Codes

Appendix B - Card Scheme IDs

Appendix C - Response Codes