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;
POST - Request
Authentication is completed via a
POST request to the test URL shown below.
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.
POST must contain the below data.
|Field Name||State||Data Type||Description|
|grant_type||Mandatory||String||Authorisation type required to confirm the action required.|
|scope||Mandatory||String||Confirm scope of the action to be performed with credentials.|
|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.|
|terminal||Mandatory||String||Provided to the integrator following the successful creation of a test account.|
payment integration_embedded and
payment integration_seamless are not enabled by default as they require you to handle raw card data, which carries significant risk. Please contact us if you wish to have either enabled.
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|
Example Request and Response
You can choose how to initiate the payment for the cardholder. A simple 'Pay Now' button would be via our Direct Integration. The Widget approach is slightly more complex, but allows you to render multiple Payment Methods, within your Checkout page.
You include a simple button that calls the payment function.
The payment window is generated when it is clicked.
In this case, it is a Lightbox/iFrame but you can do a page redirect if desired.
It is possible to support Additional Payment Methods via the Direct approach. These will be rendered in the Lightbox or Redirect.
Please get in touch if you have any questions about your approach.