The Adflex payment API is a comprehensive set of RESTful API based web services which allow you to implement card payment processing into your applications. Our APIs are delivered through seamless cloud integration to cover a wide range of payment processing methods and security measures, such as tokenization, strong customer authentication (SCA) and card on file (CoF). We also cover the full spectrum of card processing environments, including customer-not-present, customer present, eCommerce, B2B level 3 and travel enhanced data.

There are three groups of APIs: Core, PayPage, and Payment Links.

A collection of low-level payment APIs not bound by any session state mechanism.

A session-based API set designed to satisfy PCI DSS compliance. Combine the PayPage API with our JavaScript widget to capture card details outside your system, and inside our PCI compliant system.

Payment Links
An API allowing you to create links, which can be sent to a customer in order to request a payment. Messages can be configured which will be sent to the payer by Adflex, or you can implement your own solution to send URLs to your customers.

You can use these API groups together to create a PCI compliant, hybrid-payment process. e.g. Capturing and tokenising a card using the PayPage API, followed by authorisation and settlement using the Core API.

PCI DSS (Payment Card Industry Data Security Standard) Compliance

Adflex is a fully PCI DSS compliant payment processor.

To minimise your PCI burden, and achieve PCI SAQ-A compliance, use our PayPage solution.

If you intend to capture and store the card details yourself, you can use our Core API. However, this will bring you within scope of PCI-DSS SAQ (Self Assessment Questionnaire) A-EP or PCI DSS SAQ D compliance.

Getting Started

To get started, create an Adflex sandbox account.

Once registered, you will receive the following:

  • A Postman Environment JSON file, containing your secret, access keys and adflex account code.
  • A Postman JSON Collection file, containing the complete Adflex API method templates, including javascript code to create the JWT authentication token.

Calling the API

The Adflex RESTful API uses a JSON format for both requests and responses. HTTP is used to transmit requests and responses to and from our servers. The following table summarises the HTTP methods used in conjunction with the resource endpoints detailed in our API documentation.

HTTP Verb CRUD Description
Used for creating resources.
Used for retrieving resources.
Used for updating resources.
Used for deleting resources.

Every request must be transmitted using HTTPS, to encrypt your customers' data.

API Authentication

In order to ensure the security of our APIs, we have implemented a robust authentication methodology.

Each API request must contain a new JWT (JSON web token), signed with a Secret Key. The merchant creates the JWT, and the Secret Key itself is not included in the request. You will be provided with this secret key (which is created by Adflex) when you sign up with a new merchant account.

You must treat the Secret Key as a secret - securely encrypted on your system and never transmitted.

The Secret Key is accompanied by an Access Key. The Access Key is submitted in the header of the API HTTP request, along with the JWT authentication token.

Key Name Description Created By Prefix Max Length (characters) Resource Lifetime API AHPP Transmission
secretKey Secret Key Adflex sk_* 4000 Supplied by Adflex during sign-up Static: ~1 year Y N Never transmitted!
accessKey Safe Pointer to Secret Key Adflex ak_* 4000 Supplied by Adflex during sign-up Static: ~1 year Y N API request header
authenticationToken API Authentication Customer Bearer * none JWT created by merchant Dynamic: per api call; max 240 mins Y N API request header
sessionID AHPP Session Adflex sn_* 4000 /ahpp/session Dynamic: per AHPP transaction; max 240 mins Y Y Merchant JS library

Creating a JWT Token

Many programming languages offer extensive support to help you implement JWT authentication in your system - a list of libraries has been compiled at

Create the header for the JWT token - all elements are mandatory.

{ "alg" : "HS256" , "typ" : "JWT" , }

Description: alg Algorithm (HS256). typ Type.

Create the body for the JWT token - all elements are mandatory.

Payload { "jti" : "df30eba7-5062-4804-9061-4e321585540b" , "aud" : "" , "iss" : "Adflex" , "iat" : "1558452885" , }

Description: jti Unique GUID per request. aud The fully qualified resource endpoint for the current request. For example: "". iss Issuer; value must always be "Adflex". iat Issued time; please use NumericDate format as per RFC 7519.

You must encode the secret key into a byte array using UTF-8, before using it to sign the token.

Once you have created the JWT token, submit it in the "Authorization" header of the request as "Bearer {JWTtoken}".

The Authentication Flow

The Authentication Flow

Processing a Payment

When a customer makes a payment using a Credit or Debit card, a complex sequence of operations is fired off. Just a few seconds after requesting the payment, you'll receive a response indicating whether or not the transaction has been Authorised, but during that short period an extensive series of security checks, communications and analysis of the trustworthiness of the transaction have all taken place. This whole process happens quietly behind the scenes.

In the majority of cases, a transaction will be approved quickly and the payment will be made rapidly into the merchant's account. However, various factors may complicate a transaction. For example, a customer can dispute a transaction - leading to a "Chargeback", if they are successful. When an unusual situation such as this occurs, a broader understanding of what is happening can help. We are here to guide you through this process as efficiently and as painlessly as possible.

Depending on the type of environment you are processing payments in, the exact steps taken may differ slightly. Here are some of the environments in which you can process payments using Adflex:

  • Cardholder not present
  • Mail order
  • Telephone order
  • eCommerce
  • Application-initiated eCommerce

In payment processing, the full process to complete a card payment usually takes about three working days, during which it passes through distinct stages, such as Authorisation, Clearing and Settlement.

This is the first phase of a transaction. In this step, the "Issuer" of the card will attempt to confirm that an authorised user of the card has initiated the transaction. If the payment is being made in an eCommerce environment, EMV 3D Secure is used to authenticate the transaction.

If the card issuer is satisfied that the transaction should take place, the transaction amount is 'ring-fenced' on the payee's account. At this point, there is no transfer of funds between the cardholder and the merchant, but the spending limit on the card will be reduced by the transaction amount.

This is the final phase, in which authorised funds are transferred from the cardholder to the merchant.


If the transaction is being made as part of an eCommerce transaction, you must first authenticate the transaction using EMV 3D Secure, which is a mandatory additional layer of fraud security implemented by the card schemes, before you request an authorisation.

3D Secure adds an additional step to the online checkout process. The cardholder is redirected to a page hosted by the card issuer, where they are challenged on their identity.

In order to implement this in your own solution, you must send a request to the /threedsecure/authenticate endpoint using the Adflex API. The response will contain the URL for the 3DS page, at which the payer can validate the transaction.

Please note that if you are using our Hosted Pay Page solution, we will conduct this step for you when we capture the payer's card details.

Capture Mode
When you authorise a payment, you must populate the transactionDetails.captureMode with the environment in which you are performing the transaction (e.g. Cardholder not present, eCommerce, etc.).

Note: This is not to be confused with the 'capture' process as used in payments taking place in the USA, which relates to part of the settlement process.


The first step you need to take in order to execute a card payment, is to request an authorisation.

This can be done by calling/ahpp/authorisation/token if you are using card details you have securely tokenised via our AHPP (Adflex Hosted Pay Page) solution, or /transactions/authorisation if you are directly submitting card details to our Core API.

When we receive your request, Adflex's bespoke systems will process the data you have submitted and initiate communication between the Acquiring Bank (the merchant's bank account), the Issuing Bank (the cardholder's bank account), and the Card Scheme. Based on the responses we receive and the configuration within your account, you will then receive a response indicating whether the payment has been authorised or declined.

If you request an authorisation for a transaction using the Adflex API and receive a response containing a responseObject.statusCode of "Authorised", and an responseObject.transactionDetails.authCode number, the transaction will be honoured and paid.

Here are two circumstances in which there may be a risk of not getting paid:

  • An extended time (typically > 10 days) between authorising and settling the card.
  • When a cardholder initiates a chargeback - if successful, the cardholder will be reimbursed if there is suspect fraud or if the proper authentication steps have not been completed.

Authorisation Outcomes

When you submit a request for a payment to be authorised, you will usually receive a response containing a statusCode of "Authorised".

If this is the case, the transaction was successful, and the settlement process will then be able to take place, depositing the payment amount into your merchant bank account.

However, depending on a several factors, you may receive a different response. Here are some of the statuses you may receive when attempting to authorise a payment:


The merchant has received approval from the card issuer, and the requested funds have now been ringfenced but not yet deducted (settled) from the cardholder's account. Following an authorised transaction, you can confirm to the user that the payment has been successful.


The card issuer has refused the authorisation request. Following a decline, a second attempt to authorise the transaction is unlikely to be approved. Instead of returning the user to the payment screen in order to try again, we suggest that you direct them to either use a different card or contact their card issuer for further information on why the transaction has been declined.


If you receive an error status, please refer to the subCode and statusMessage properties of the response object, as they will be able to provide you with further information on why an error has occurred.


A referral is also known as a soft decline, in which the issuing bank requires further information from the cardholder to authorise the payment. Typically, a referral is treated similarly to a decline by payment applications. Referral statuses are now mostly obsolete as 3D Secure has largely replaced the process.


The reversal process is designed to reverse (remove) the reserved (ring-fenced) amount on the card if called very shortly (typically hours) after the execution of an "authOnly" transaction. Adflex is currently working with specific acquirers on supporting the "enhanced reversals" process which will work on "authOnly" transactions greater than a few hours old. We expect this to be introduced within the next few months, once we have fully implemented the current PSD2 SCA and Credentials on File compliance work.

You can request a reversal of a transaction by calling the /transactions/reversal endpoint in the Adflex API.


'Settlement' is the process of transferring an authorised payment's funds from the cardholder's account into the merchant's bank account.

In order to settle a transaction which you have previously authorised, please call the /transactions/settle endpoint in the Adflex API.

The Adflex API can be used to implement two types of settlement models.

Authorise and Settle
An Authorisation followed by an Adflex invoked automatic settlement at the end of the day.

To operate this model, you must call the /ahpp/authorisation/token or /transactions/authorisation endpoint using the Adflex API, taking care to set the transactionDetails.processMode property to "AuthAndSettle".

Authorise Only
An Authorisation without automatic settlement.

To operate this model, you must first call the /ahpp/authorisation/token or /transactions/authorisation endpoint using the Adflex API, taking care to set the transactionDetails.processMode property to "AuthOnly". If the card issuer is satisfied that the transaction should take place, the transaction amount is 'ring-fenced' on the payee's account.

When you wish to settle the transaction, the you must call the /transactions/settle endpoint. If the settle endpoint is never called, the authorisation for the transaction will naturally expire after a period of time; typically between five and ten working days, depending on the card issuing bank.


Refunds are managed by the merchant. By making an API request to the /v2/transactions/authorisation/token endpoint with the property transactionDetails.type set to "Refund", you can execute a refund.

A cardholder is unable to initiate a refund for a transaction made from their account.

'Delayed Shipment and Charge' Model

There are two ways in which you can operate a delayed shipment and charge model (using the Adflex Hosted PayPage).

Option 1
Reserve, without deducting, the funds from the card (ring-fence the charge value at the point of order):

  1. Create an Adflex Hosted PayPage Session, by making a request to the /ahpp/session endpoint exposed by the Adflex API, taking care to set the tokenLifetime.saveCardOption, and tokenLifetime.ttlDays values to the required card storage values.
  2. Invoke the widget within your customer-facing website to capture and tokenise the card details.
  3. Immediately after the card is captured, call the /ahpp/authorisation/token API endpoint, with the property transactionDetails.processMode set to "authOnly".
  4. Later, at the moment of dispatch, call the /transactions/settle API endpoint to request the transfer (or 'settlement') of the ring-fenced funds from the payee's card into your account. Please note that you should ideally request the settlement within 4-10 days of the original "authOnly" transaction.

The advantage for the merchant, is that there is a high probability of receiving the ring-fenced funds on dispatch and settlement.

The disadvantage for the cardholder is that their card spend limit will be reduced for the period prior to the dispatch of the goods, but the funds will only be taken from their account once you have dispatched the goods. This is commonly referred to as a "shadow" on the cardholder's card.

If, for any reason, the merchant is unable to dispatch the goods (e.g. if the order cancelled or the required stock is unavailable), the card-holder's spending limit will continue to be reduced until the original Authorisation naturally expires. This is not a limitation of Adflex's systems, but a consequence of how card payments are handled within the UK.

Option 2
Authenticate and tokenise the card, followed by a zero value authorisation only:

  1. Create an Adflex Hosted PayPage Session, by sending a request to the /ahpp/session endpoint exposed by the Adflex API, with an amount.value of "0", taking care to set the tokenLifetime.saveCardOption, and tokenLifetime.ttlDays values to the required card storage values.
  2. Invoke the widget within your customer-facing website to capture and tokenise the card details.
  3. Immediately after the card is captured, call the /ahpp/authorisation/token API endpoint, with the property transactionDetails.type set to "AccountVerification", and amount.value set to "0".
  4. Later, at the point of dispatch, call the /transactions/authorisation/token API endpoint using the previously tokenised card, with the amount.value set to the required transaction value.
  5. Immediately afterwards, call the/transactions/settle API endpoint to request the transfer (or 'settlement') of the funds from the payee's card into your account.

The disadvantage for the merchant is a possibility that the card has insufficient funds to pay for the shipment.

The advantage for the cardholder is that their card spend limit will not be reduced for the period prior to the dispatch of the goods, and the funds will only be taken once the goods have been dispatched.

Card Security Options

AVS is a Cardholder not Present (CNP) fraud detection process, based on passing the address information captured during the checkout process directly to the cardholder's issuing bank for verification. Once checked the issuer then returns a code, indicating their level of certainty regarding the address's validity. This code is then passed through our rules-based checking system and will contribute towards a 'transaction acceptance score'. Please note that AVS does not work as reliably for transactions made with corporate cards, where the card's registered address often differs to that of the cardholder.

CSC (also referred to as CVC or CVV) is a three to four-digit security code that should be known only to the cardholder. We will request this code during the checkout process, and submit it to the cardholders issuing bank for verification. The response is then passed through our rules-based checking system and will contribute towards a 'transaction acceptance score'. A failed CSC transaction should never be accepted!

When is an AVS/CSC check performed?
Adflex performs AVS/CSC checks when you request an authorisation. AVS/CSC rules are agreed at the time of signing up with Adflex and are configured at the merchant account level. If the outcome is to reject the transaction, Adflex will attempt to execute a reversal to cancel the transaction.

We will apply these rules across all transactions processed within the merchant account, unless you choose to manually override them for a specific transaction.

EMV 3D Secure (also referred to as 3D Secure or 3DS) is a mandatory cardholder authentication service implemented by the card schemes, in order to reduce fraud in eCommerce environments. The advantage of 3D Secure is that as a merchant, once you have carried out a successful authentication of the cardholder for a specific transaction using 3D Secure, you are no longer liable for this transaction should a fraud claim arise. The number of chargeback cases raised against you should therefore reduce significantly.

Security Best Practice

When handling payments within your system, you must take care to build a solution with security implications at the forefront of concerns. There are several publicly available resources which can provide technical advice and details on common security mistakes and exploits.

We recommend following the guidelines published by OWASP to protect both your company and your customers from fraud and loss of data.

  • The OWASP Top Ten is a list of OWASP's top ten most critical security risks to web applications. We strongly recommend that you take steps to mitigate these potential vulnerabilities when building your solution.
  • OWASP's Cheat Sheet Series is a set of simple good practice guides for application developers. This is a useful resource for building secure applications, offering guidance for specific aspects of your solution or technology of choice.
  • The OWASP Web Security Testing Guide provides helpful advice on testing web applications to ensure a high level of security.

Please ensure you avoid the following design errors when building your payment solution.

Failing to use HTTPS

Always use HTTPS to secure your website. All of Adflex's APIs use HTTPS for both requests and responses, to prevent sensitive communications from being intercepted by third parties.

Transmitting or failing to keep your API secret key encrypted

Your security credentials for the API must be kept secure and encrypted on your system. At no point should you ever transmit these to a third party, or serve them to a browser via your website.

When you access the API, use the security key to create a JWT token which is submitted as a header to authenticate the request.

When using Adflex's Hosted Pay Page, it is necessary to call our API from the customer's browser. In this case, authentication takes place via session IDs and tokens which are passed to the browser, so it is not necessary to send your security credentials to the browser.

Passing sensitive information to the browser

Never send sensitive data (especially relating to personal or card details) to the customer's browser. Process sensitive data on your server rather than in the browser. Once you have transmitted information to a customer's browser, it is out of your control, and you are reliant on the customer's environment for security.

MID (Merchant ID) Selector Rulebase

The MID (Merchant ID) Selector Rulebase is a feature built into your Adflex Gateway Account. It enables a merchant acquirer account to be selected based on one of the following conditions;

  • BIN Range
  • Card Scheme
  • Value Range
  • Enhanced Datatype
  • Country Code
  • Currency Code
  • Card Number Regex Pattern

Each rule has a priority number and is bound to a merchant acquirer account.

Rules can be chained (logical OR) together and tested in priority order for each transaction. For example;

  • Your web site can accept Visa, Mastercard and AmexCPC cards. The merchant's system uses our hosted paypage solution and has no way of knowing what card the shopper will use as the merchant is shielded from seeing the card number.
  • AmexCPC cards must be processed directly using an Amex merchant account and not the same merchant account you would use for Visa / Mastercard, e.g. Worldpay.

Create a rule to detect an AmexCPC card that will route directly to Amex. Everything else routed to the following rule for testing. If no match, then use the default merchant acquier account, which in this example is Worldpay.

These rules are configured by Adflex working with the merchant at the time of the initial account creation.

Transaction Rulebase

The Transaction Rulebase is a feature built into your Adflex Gateway Account. It enables a transaction to be accepted or rejected based on the MID and the 3DS, CVC and AVS responses.

Each rule set is grouped by

  • Transaction Value Lower
  • Transaction Value Upper

And tests against the following rules;

  • Allow Non-3DS Cards
  • Allow non 3DS Merchants
  • Allow 3DS Failures
  • Allow 3DS MPI/Server Failures
  • Allow Non-Matched CVC
  • Allow Non-Matched Address
  • Allow Partial Matched Address
  • Allow Non-Matched Postcode
  • Allow Partial Matched Postcode

For example;
If a transaction AVS Postcode=NotMatched and Allow Non-Matched Postcode is not ticked, then the transaction will be forced to status Declined.

Another example;
If a transaction AVS Postcode=NotMatched and Allow Non-Matched Postcode is not ticked, then the transaction will be forced to status Declined.

In the Adflex Paypage solution, these rules can be overridden on a transaction by transaction basis using the following /ahpp/session properties;

  • "tdsCheck"
  • "cvcCheck"
  • "avsCheck"

Refer to the /ahpp/session documentation for the available options

Note that the 3DS, CVC and AVS response values are returned in the API irrespective of the rule actions. Except for when using the Paypage to creating a token only. In this case, you will need to set the /ahpp/session request property “accountVerification”: true and to call /ahpp/accountverification/ at the end of the step to retrieve the values.


Test Cards

We have made a range of test cards available for you to test a variety of processing scenarios, such as Authorised, Declined and Error statuses, for Debit, Credit and B2B payment cards.

Level 1 CREDIT Cards
Outcome MasterCard MasterCard 2 Range Visa Amex Retail
Auth 5185 5110 0000 0010 2223 0000 1001 1804 4012 0010 3627 5556 3782 8224 6310 005
Decline 5185 5150 0000 0045 2223 0000 1001 0095 4012 0010 3629 8889 3782 8224 6317 000
Refer 5185 5150 0000 0052 2223 0000 1001 0202 4012 0010 3685 3337 3782 8224 6320 004
Error 5185 5110 0000 0002 2223 0000 1001 0194 4012 0010 3698 3332 3782 8224 6319 006
Level 3 CREDIT Cards
Outcome MasterCard Visa Amex CPC
Auth 5569 5100 0000 0018 4715 0570 0000 0107 3742 9048 2911 992
Decline 5569 5000 0000 2296 4715 0570 0000 0123 3742 9048 2907 990
Refer 5569 5000 0000 2312 4715 0570 0000 0164 3742 9048 2920 993
Error 5569 5000 0000 2338 4715 0599 9900 0437 3742 9048 2919 995
Level 1 DEBIT Cards
Outcome MasterCard Visa Visa Electron Maestro Intl Maestro
Auth 5573 4899 0000 0028 4137 3356 0011 7780 4844 2155 0011 5643 5033 9619 8900 0008 18 6799 9901 0000 0000 019
Decline 5573 4899 0000 0721 4137 3356 0011 0785 4844 2155 0011 7649 5033 9619 8900 0381 15 6799 9901 0000 0000 076
Refer 5573 4899 0000 2024 4137 3356 0011 2088 4844 2155 0012 0643 5033 9619 8900 0320 19 6799 9901 0000 0000 209
Error 5573 4899 0000 1927 4137 3356 0011 1981 4844 2155 0011 9645 5033 9619 8900 0319 12 6799 9901 0000 0000 191
3DS v1 Test Cards
PAN Enrolment Status Error Code Response
51674 (TDSNotSupportedByCard)
Cardholder is not enrolled for 3D Secure
51675 (TDSFailedVERES)
Unable to process
50001 (Ok)
Successful Payer Authentication


  • Use any date in future for Card Expiry Date.
  • You must not use Adflex test cards in any live or production environment.
  • For cards that have an outcome of Authorised, you may use the CSC (Card Security Code) value as follows:
Position Name Values
1 CSC 1=Unchecked, 2=Matched, 4=NotMatched, >4=NotMatched
2 AVS Postcode 1=Unchecked, 2=Matched, 4=NotMatched, >4=NotMatched
3 AVS Address 1=Unchecked, 2=Matched, 4=NotMatched, >4=NotMatched
4 Force Decline 0=No, 1=Yes
  • CSC=2220
    produces a response with the following attributes: CVC=Matched; Postcode=Matched; Address=Matched; Status:Authorised
  • CSC=2421
    produces a response with the following attributes: CVC=Matched; Postcode=NotMatched; Address=Matched; Status:Declined

For the above scenarios, please do not use any numbers in the address/postcode fields, as this could produce unexpected results.


To get you up and running quickly, we recommend that you use a free tool called Postman. With Postman you can execute API calls, using a collection of predefined method templates created by Adflex.

Once you have downloaded and installed Postman, please import the following two files, via the User Interface, to configure your Adflex API test environment.

  • The Postman Environment file provided when you register for an Adflex Sandbox account, containing your secret, access keys and adflex account code.
  • The Adflex API Postman Collection file, containing the complete Adflex API method templates for each resource and including the javascript to create the JWT authentication token.