Welcome to Acquired Docs

This site contains Acquired's developer resources. You will find everything you need to integrate with our platform including technical documentation, sample code and test card details.

Getting Started

In order to utilise the Acquired API you will initially require access to our QA environment.

Once your account has been confirmed Acquired will provide you with company_id, company_pass and hash code details which are required for all request types. You will also be granted access to the Acquired Dashboard allowing you to review and manage your transactions.

Integration Methods

In addition to providing a robust API solution and hosted payment page, Acquired are capable of processing both via a virtual terminal to facilitate MOTO payments and also via bulk files for the authorization and management of transactions.

In order to get started you will need to pick an authorisation solution that best suit your businesses requirements.

The Acquired Hosted Payment Page solution captures sensitive card data for you, reducing your PCI DSS burden and increasing your security. It has been built to provide you with complete control. Your code, just hosted by us.

If you would like to discuss your requirements in more details please contact [email protected]

Hosted Payment Page

Overview

The Acquired Hosted Payment Page solution captures sensitive card data for you, reducing your PCI DSS burden and increasing your security. It has been built to provide you with complete control. Your code, just hosted by us.

PCI DSS

The Acquired HPP solution hands complete control to the merchant while allowing them to remain eligible for PCI DSS SAQ A.

Templates

Unlimited dynamic templates letting you decide what is displayed depending on screen size and device.

Configuration

The hosted payment page solution is created at a MID level within the Acquired portal. In order to create / upload a HPP for a specific MID please go to the following section, “Merchant -> Company & MID -> Create” as shown in the screenshot below:

A default template for the Acquired HPP is available within the dashboard for download as a starting point for your design. More information on how to customise your payment page can found here.

Endpoints

The endpoints for the Acquired Hosted Payment Page are:

QA: https://qahpp.acquired.com

PROD: https://hpp.acquired.com

Security

This section describes the additional security checks that are put in place to ensure transactions submitted to Acquired can be confirmed as genuine requests from our merchants.

Referring URL

A referring URL is the URL from which a merchant redirects their customer to the Acquired HPP. Acquired will only accept requests from URLs that have been whitelisted within the portal. This can be done within the configuration section at a MID level for the HPP under the tabs “Company and MID -> HPP -> Edit”.

Please note that merchants must have one or more referring URL(s) confirmed for the production environment. The referring url must always begin with https://.

Generating the Hash

In order to generate the hash value, which must be submitted with every request, merchants must complete the following steps:

All parameters (excluding company hash) that are being submitted in the POST must be sorted alphabetically and then concatenated.

Request

A form with hidden html fields containing the customer order data must be integrated into the merchants referral page, i.e. the final page on the merchant's website prior to redirecting the customer to the Acquired environment. This order data is then submitted via a POST to Acquired, the payment page is then loaded and the customer will be prompted to enter their sensitive cardholder data. Please see the example below:

Request Parameters

Although there are limited mandatory fields required in order to process a HPP transaction, we recommend supplying additional information as part of the request in order to fulfil additional security checks such as AVS (where available).

For merchants categorised as MCC 6012, the customer_lname, customer_dob and billing_zipcode parameters must be submitted in the request to comply with Scheme Mandates. If you are unsure of your MCC classification please contact [email protected].

Response

Acquired provide two options for merchants to receive the results of the transaction following authorisation within the hosted environment. Both options can be used in tandem to ensure that responses are not lost due to unforeseen circumstances including connection issues between Acquired and the merchant’s servers.

Return URL

The Return URL is used to redirect customers from the Acquired environment back to the merchants website following the authorisation step of the payment process.

A default value can be set in the Acquired portal under the HPP configuration but it is also possible to dynamically change the endpoint within each individual request by passing the returnurl parameter in the request to the HPP.

Callback URL

Merchants can set a Callback URL to address scenarios where the transaction response is not successfully received. Some such examples may include:

Customer’s closing their browser before being redirected back to the merchant

Temporary connection issues with merchants servers

Issues with communication over the internet in general.

In order to resolve this issue Acquired has introduced the Callback URL to provide direct server-to-server feedback allowing merchants to receive every response, every time.

A default value can be set in the Acquired portal under the HPP configuration but it is also possible to dynamically change the endpoint within each individual request by passing the callbackurl parameter in the request to the HPP.

In the event that we do not receive back a HTTP 200 response from your server we will reattempt to establish a connection (5 times in 5 minute intervals) to ensure your system is up to date with all order details.

Verifying the Response

As detailed in the previous sections, contained within the response to both the Return URL and Callback URL is the parameter hash which allows merchants to confirm that the response came from Acquired.

All parameters (excluding hash) that are returned in the response must be sorted alphabetically and then concatenated.

In addition to the transaction specific response parameters detailed in the table above all values shown here, when submitted in the request or gathered on the HPP, will be returned in the response.

PARAMETER

FORMAT

LENGTH

DESCRIPTION

billing_city

string a-z A-Z 0-9 , . - _

1-100

The city of the cardholder’s address.

billing_country_code_iso2

string a-z A-Z

2

The ISO 3166 2-character country code of the cardholder’s address. Please see here.

billing_email

string 0-9 a-z A-z _ - . @

1-50

The cardholder’s billing email address.

billing_phone

string 0-9 ( ) + -

7-20

The cardholder’s billing phone number.

billing_state

string a-z A-Z 0-9 , . - _

1-100

The state or province of the cardholder’s address.

billing_street

string a-z A-Z 0-9 , . - _

1-100

The cardholder’s street address.

billing_street2

string a-z A-Z 0-9 , . - _

0-100

The cardholder’s street address, line 2.

billing_zipcode

string a-z A-Z 0-9 , . - _

1-50

The cardholder’s billing ZIP or postal code.

customer_company

string a-z A-Z 0-9 , . - _

0-50

The customer’s company.

customer_dob

string 0-9 in the format YYYY-MM-DD

10

The customer’s date of birth in YYYY-MM-DD format.

customer_fname

string a-z A-Z , . - _

0-50

The customer’s first name.

customer_gender

string M / F

1

A one character code indicating the customer’s gender.

customer_ipaddress

string IPv4 / IPv6

0-50

The customer’s IP address used in submitting the transaction. 7 to 15 numeric characters in XXX.XXX.XXX.XXX format.

customer_lname

string a-z A-Z , . - _

0-50

The customer’s last name.

customer_mname

string a-z A-Z , . - _

0-50

The customer’s middle name.

customer_title

string a-z A-Z , . - _

0-20

The customer’s title such as Mr. or Mrs.

merchant_custom_1

string a-z A-Z 0-9 , . - _

0-50

Merchant custom data.

merchant_custom_2

string a-z A-Z 0-9 , . - _

0-50

Merchant custom data.

merchant_custom_3

string a-z A-Z 0-9 , . - _

0-50

Merchant custom data.

merchant_customer_id

string a-z A-Z 0-9 , . - _

0-50

The unique customer ID used by the merchant to identify the customer.

Styling

In order to provide our merchants and your customers with a truly seamless checkout experience, Acquired have designed our HPP solution to give you complete control over the look-and-feel of the payment page.

We have achieved this by allowing our merchants to write their own HTML and hosting it for them. The advantage of this is not only a better checkout experience but as we also facilitate the hosting of CSS, JavaScript, Image and Font files. Merchants who utilise our HPP solution complete PCI DSS SAQ A, limiting the costly and complex burden of compliance.

In order to make our solution as flexible as possible, each element of the payment form has been assigned a placeholder which simply needs to be included to either display information passed through in the request or to gather additional information during checkout

Please note: Within the template uploaded to the Acquired portal the below line needs to be included:

Uploading the Template

Within the Acquired portal, templates can be uploaded under the Company and MID section as shown in the below screenshot.

Templates can be uploaded through the Acquired portal on the HPP configuration tab under the Company and MID section.

The HTML file must be named index.html and all files must be contained within one zipped file that does not contain any additional folders.

Acceptable File Types: .html | .css | .js | .png | .jpg | font files

Once uploaded the files will be reviewed by the Acquired Support Team and marked as available, at this point the template is ready for use.

Default Template

It is possible to set a default template in the Acquired portal which will be displayed if no "template_id" parameter is populated in the request:

Dynamic Template

In order to dynamically change the template displayed to the customer, the “template_id” parameter will need to be included in the HPP request containing the unique identifier assigned to each uploaded file. This value is shown in the HPP section of the portal once the template has been created:

Placeholders - Card Details

In order to create the payment form you will need to set the following placeholders as the value in the HTML form:

Parameter

Placeholder

Description

cardholder_name

{{cardholder_name}}

Cardholder Name.

cardnumber

{{cardnumber}}

Card Number.

card_type

{{card_type}}

Card Type.

cardexp

{{cardexp_month}}

Card expiry month.

cardexp

{{cardexp_year}}

Card expiry year.

cardcvv

{{cardcvv}}

CVV2 Value.

subscription_type

{{is_remember}}

Flag to initiate a RECUR_INIT subscription.

settlement_url

{{settlement_url}}

The form action value for the request within the template.

hpp_id

{{hpp_id}}

The unique id for the session of the HPP.

An example template showing how to incorporate these placeholders into your template is available in the Acquired portal. To request a test account please contact [email protected].

Placeholders - Request Parameters

It is possible to display any parameter passed through in the request on the HPP by including the relevant placeholder within the template. It is also possible to capture these parameters on the HPP in a similar way to the card details if required.

Parameter

Placeholder

Description

amount

{{amount}}

The amount of the transaction.

billing_city

{{billing_city}}

The city of the cardholder’s address.

billing_country_code_iso2

{{billing_country_code_iso2}}

The ISO 3166 2-character country code of the cardholder’s address.

billing_email

{{billing_email}}

The cardholder’s billing email address.

billing_phone

{{billing_phone}}

The cardholder’s billing phone number.

billing_state

{{billing_state}}

The state or county of the cardholder’s address.

billing_street

{{billing_street}}

The cardholder’s street address.

billing_street2

{{billing_street2}}

The cardholder’s street address, line 2.

billing_zipcode

{{billing_zipcode}}

The cardholder’s billing ZIP or postcode.

currency_code_iso3

{{currency_code_iso3}}

The currency of the transaction.

customer_company

{{customer_company}}

The customer’s company.

customer_dob

{{customer_dob}}

The customer’s date of birth.

customer_fname

{{customer_fname}}

The customer’s first name.

customer_gender

{{customer_gender}}

A one character code indicating the customer’s gender.

customer_ipaddress

{{customer_ipaddress}}

The customer’s IP address used in submitting the transaction.

customer_lname

{{customer_lname}}

The customer’s last name.

customer_mname

{{customer_mname}}

The customer’s middle name.

customer_title

{{customer_title}}

The customer’s title such as Mr. or Mrs.

merchant_custom_1

{{merchant_custom_1}}

Merchant custom data.

merchant_custom_2

{{merchant_custom_2}}

Merchant custom data.

merchant_custom_3

{{merchant_custom_3}}

Merchant custom data.

merchant_customer_id

{{merchant_customer_id}}

The unique customer ID used by the merchant to identify the customer.

Recurring

Overview

Acquired’s system has been designed to support recurring payments. This allows merchants offering subscription services to their customers to utilise our services.

The three types of operations that can be submitted by merchants wanting to implement recurring payments are:

INIT: Used to initiate a subscription that will result in a customer’s card number being stored in Acquired’s system in an encrypted format for future use.

REBILL: Used to make subsequent charge of existing subscriptions.

REUSE: Used to make process a new transaction against stored card details where the customer is present and able to enter their authentication (CVV and 3-D Secure) details.

INIT

An initialisation operation authorises Acquired to securely store an encrypted copy of a customer’s card number on our systems, for future use. Use the INIT value for the subscription_type parameter to perform an initialisation operation.

INIT Request Parameters

The following table describes the parameters used in the INIT transaction request. These values must be processed in addition to those detailed in the API Guide for AUTH_ONLY and AUTH_CAPTURE request types as shown in the example above:

PARAMETER

FORMAT

LENGTH

DESCRIPTION

subscription_type

string a-Z A-Z _

4 - 14

INIT activates a card for the subscription services and authorises Acquired to securely store an encrypted copy of a customer’s card number on our systems, for future use. Accepted values are: INIT, REBILL.

The response is the same as a regular authorisation transaction type which can be found here.

REBILL

A rebill operation authorises Acquired to decrypt a previously stored card number and to use that card as the payment method for this rebill transaction. Use the REBILL value for the subscription_type parameter to perform a subsequent charge of existing subscription without sending customer and billing info again.

REBILL Request Parameters

REBILL authorises Acquired to decrypt a previously stored card number and to use that card to rebill a customer. Accepted values are: INIT, REBILL.

original_transaction_id

int 0-9

1-11

The transaction_id value returned in the transaction response of the original INIT authorisation request.

Note the customer and billing parameters should be omitted from the REBILL operation.

The response is the same as a regular authorisation transaction type which can be found here.

REUSE

A reuse operation authorises Acquired to decrypt a previously stored card number and to use that card as the payment method for this reuse transaction. Use the REUSE value for the subscription_type parameter to perform a subsequent charge where the cardholder is present on your website.

Please see the example below of a REUSE authorisation request including both CVV and 3-D Secure:

If you would like to update the card details but not charge the customers at this time submit a zero value authorisation in the request with the transaction_type set to AUTH_ONLY. Acquired will confirm the card details are correct with the issuing bank and only update the stored details if successful.

UPDATE_BILLING Request Parameters

The following table describes the parameters used in the UPDATE_BILLING transaction request. These values must be processed in addition to those detailed in the API Guide for AUTH_ONLY and AUTH_CAPTURE request types as shown in the example above:

PARAMETER

FORMAT

LENGTH

DESCRIPTION

subscription_type

string a-Z A-Z _

4 - 14

UPDATE_BILLING instructs Acquired to update the stored card and customer data associated with a token reference if the transaction is successfully authorised with the cardholders issuing bank.

3-D Secure

Please note if you are processing via the HPP you only need to include the "is_tds" parameter in the request to enable 3-D Secure. Please see here for further information

Overview

3-D Secure is a cardholder authentication framework developed by the Card Schemes; Visa, MasterCard and American Express. It aims to reduce the risk of chargebacks to merchants by requiring cardholders to log onto their own bank's website before each online transaction. This pushes the liability for the transaction back to the cardholder as only they should know the login passphrase. In the event the bank cannot check the authenticity of the cardholder's entry but they do acknowledge the attempt, the liability passes to the Issuing Bank. For Visa or MasterCard transactions, if the cardholder has not been enrolled in 3-D Secure, the liability will also shift to the Issuing Bank.

Each of the Card Schemes have branded their offering of 3-D Secure differently. For Visa cards it is know as "Verified by Visa" and for MasterCard it is "SecureCode".

Please note: Chargeback protection is subject to further conditions outside of those outlined within this document. Merchants should check with their Acquiring Bank regarding their own chargeback rules.

Configuration

3-D Secure Flow

The 3D Secure process involves a number of steps which we've summarised below. We're presuming here that the merchant only wishes to accept transactions that provide chargeback protection.

Verify if the cardholder's card is enrolled in 3D Secure (ENQUIRE). If the card is not enrolled, depending on your account configuration, Acquired will send the transaction to your acquiring bank for authorisation.

If the card is enrolled, redirect the cardholder to their bank's Access Control Server (ACS) to enter their passphrase (POST TO ACS).

Take the response values from the ACS and send them to Acquired to be verified, decoded and sent onto your acquiring bank for authorisation (SETTLEMENT).

Enquire

The first stage in the 3D Secure process is verifying whether the card is enrolled or not. To do this, the card data is sent to Acquired in the AUTH_ONLY / AUTH_CAPTURE transaction request. Depending on the card type, Acquired will query the appropriate Enrolment Server and return the outcome.

ENQUIRE Request Parameters

The following table describes the parameters used in the ENQUIRE transaction request. These values must be processed in addition to those detailed in the API Guide for AUTH_ONLY and AUTH_CAPTURE request types as shown in the example above:

PARAMETER

FORMAT

LENGTH

DESCRIPTION

tds

object

actionRequired

string a-Z A-Z

7-10

Value should be set to ENQUIRE.

ENQUIRE Response

If the cardholder is not enrolled for 3-D Secure and you have chosen to accept these transactions, Acquired will submit the transaction to your acquiring bank for authorisation and return a response code other than 501 / 502. Please see here for a list of possible values.

The following is an example of an AUTH_ONLY ENQUIRE transaction response where the cardholder is enrolled for 3-D Secure:

ENQUIRE Response Parameters

The following table describes to the parameters returned in the ENQUIRE transaction response. These values are returned in addition to those detailed in the API Guide for AUTH_ONLY and AUTH_CAPTURE request types as shown in the example above:

PARAMETER

FORMAT

LENGTH

DESCRIPTION

tds

object

pareq

string Base64 encoded

1-2000

The Payer Authentication Request returned by the Enrolment Server. Must be sent to the Issuing Bank's ACS (Access Control Server) URL.

url

string a-z A-Z 0-9 ' " . , - _ / : = ?

1-2000

The address of the issuing bank's Access Control Server (ACS). Should be set as form action in POST to ACS.

enrolled

string a-z A-Z

0 / 1

The enrolement status of the card:Y: Cardholder enrolledN: Cardholder not enrolledU or Blank: Enrolment status could not be verified.

enrolled Parameter

Depending on the value returned in the enrolled parameter of the ENQUIRE response the following actions are recommended:

"enrolled":'Y' The card is enrolled for 3-D Secure please proceed to Authentication

"enrolled":'N' Acquired have either blocked the transaction or submitted it for authorisation, please see the response_code parameter.

Authentication

If the customer's card is enrolled in 3D Secure the response to the ENQUIRE request will contain two key values.

url: The address of the issuing bank's Access Control Server (ACS). Should be set as form action in POST to ACS.

pareq: The Payer Authentication Request, required to initiate the authentication.

The cardholder can now be redirected to the ACS URL to authenticate themselves. This can be achieved through a full-page redirect or by loading the page inside an iFrame. Below is a very simple redirect script as an example.

POST to ACS

The PaReq, MD and TermUrl fields must be sent to the ACS in order to initiate the authentication. The url parameter should be used as the value for the form action.

Request Parameters

PARAMETER

FORMAT

LENGTH

DESCRIPTION

PaReq Case Sensitive

string a-z A-Z 0-9 ' " . , - _ / : = ?

1-2000

The encoded pareq you received from Acquired.

TermUrl Case Sensitive

string a-z A-Z 0-9 ' " . , - _ / : = ?

1-2000

The URL that the ACS should send the outcome to in your application. It must be secured with a TLS certificate (still commonly referred to as an SSL cert).

MD Case Sensitive

string base64 encoded

0-2000

Merchant Data. It is advised to pass through the following parameters within the MD field:

transaction_id

merchant_order_id

amount

currency_code_iso3

transaction_type

These parameters are required for the subsequent SETTLEMENT request. Any information in this field should be encrypted and Base64 encoded.

Response Parameters

The following fields will be returned to the TermUrl specificed in the POST to ACS.

PARAMETER

FORMAT

LENGTH

DESCRIPTION

PaRes

string Base64 encoded

1-2000

PaRes (Payer Authentication Response). Contains the encoded confirmation of the customer's authentication status, informing the merchant whether the customer has entered their password correctly or not.This must be sent to Acquired in the SETTLEMENT request to be verified, decoded and sent to the acquirer for authorisation.

MD

string base64 encoded

0-2000

Merchant Data. Encrypted and encoded data sent previously to the ACS to be used in the SETTLEMENT request.

Settlement

The bank's ACS (Access Control Server) will return the PARes which contains encoded confirmation of the customer's authentication status. This can be sent in a SETTLEMENT request to Acquired. We will determine if the authentication signature is genuine, decode it and send onto the acquirer for authorisation.

SETTLEMENT Request Parameters

The following table describes to the parameters used in the SETTLEMENT transaction request. These values must be processed in addition to those detailed in the API Guide for AUTH_ONLY and AUTH_CAPTURE request types as shown in the example above:

The following table describes to the parameters returned in the SETTLEMENT transaction response. These values are returned in addition to those detailed in the API Guide for AUTH_ONLY and AUTH_CAPTURE request types as shown in the example above:

PARAMETER

FORMAT

LENGTH

DESCRIPTION

tds

object

status

string a-z A-Z

1

The outcome of the authentication, possible values are:

Y: The cardholder successfully authenticated.

A: The cardholder is enrolled and the bank acknowledges the attempted authentication.

N: The cardholder did not authenticate successfully - if you authorise this transaction you will be liable for any chargeback.

External MPI

Acquired support the use of 3rd party MPI solutions allowing you authenticate the cardholder and pass through the required parameters in the authorisation request. Please note that if you choose to integrate 3-D Secure in this way Acquired will only pass these fields onto your chosen acquiring bank and take no responsibility in the event of integation issues that may result in increased fees and reduced dispute protection.

Below is an example of an authorisation request where an external MPI has been used:

The response is the same as a regular authorisation transaction type which can be found here.

Query

It is possible to get the outcome of an individual transaction (for recurring payments a group of transactions) by utilising the Acquired query service.

You may also query Acquired's BIN database before processing an authorisation attempt for information on the issuing bank, card category, card level and issuing country.

There are different endpoints for this service:

QA: https://qaapi.acquired.com/api.php/status

PROD: https://gateway.acquired.com/api.php/status

Request Types

It is possible to perform a query on a "transaction_id", "merchant_order_id" or "bin" depending on what information you are looking for. Please see the table below for a complete list of possible values for the "status_request_type" parameter and what field you should use within the transaction object of the request.

status_request_type

Description

ORDER_ID_ALL

Will return a list of all response messages for transactions using the specified "merchant_order_id".

ORDER_ID_FIRST

This will return the response message for the first authorisation attempt using the specified "merchant_order_id".

ORDER_ID_LAST

This will return the response message for the last authorisation attempt using the specified "merchant_order_id".

ORDER_ID_SUCCESS

This will return the response message for the successful authorisation attempt using the specified "merchant_order_id". There can only be one successful authorisation per "merchant_order_id".

TRANSACTION_ID

Will return the response message from a specific "transaction_id".

TRANSACTION_ID_CHILDREN_ALL

Using the "transaction_id" returned in the INIT response / "original_transaction_id" in the REBILL request, will return a count and the response messages for all REBILL (success and declined) attempts processed against the customers card.

TRANSACTION_ID_CHILDREN_FIRST

Using the "transaction_id" returned in the INIT response / "original_transaction_id" in the REBILL request, will return the response message from the first REBILL attempt processed against the customers card.

TRANSACTION_ID_CHILDREN_LAST

Using the "transaction_id" returned in the INIT response / "original_transaction_id" in the REBILL request, will return the response message from the last REBILL attempt processed against the customers card.

TRANSACTION_ID_CHILDREN_SUCCESS

Using the "transaction_id" returned in the INIT response / "original_transaction_id" in the REBILL request, will return a count and the response messages for all successful REBILL attempts processed against the customers card.

BIN

By passing the first 6 digits of the card number Acquired will return more information about the card (issuing_bank, card_category, card_level, issuing_country and issuing_country_iso2).

Request Hash

As with all other transaction types you'll need a "request_hash" value in order to authenticate the request with the Acquired platform. Below is a code example for how to calculate this value for all status_request_type parameters.

Reference

CVV2 Codes

The CVV2 is a three or four digit code that is printed on debit and credit cards. The number is generally printed on the back of the customers’ card for Visa and MasterCard and on the front for AMEX.

The security code that the customer has entered is checked against the security code that the card issuer holds for their card. The customer’s bank will indicate to the acquiring bank whether there is a match between the entered security code and the correct security code associated with the card.

There are four possible results, returned in the cvvresult parameter, to the CVV2 check as shown below:

Response

Description

Comment

M

Matched

The information provided by the customer matches that on the card issuer’s records.To replicate this response in QA pass "123" in the "cardcvv" parameter.

N

Not Matched

The information provided by the customer does NOT match that on the card issuer’s records.To replicate this response in QA pass "456" in the "cardcvv" parameter.

NC

Not Checked

Your acquirer was unable to perform this check on the information provided.To replicate this response in QA pass "789" in the "cardcvv" parameter.

NP

Not Provided

Your acquirer was not provided with the information required to perform this check.To replicate this response in QA leave the "cardcvv" parameter blank.

AVS Codes

The customer’s bank will indicate to the acquiring bank whether there is a match between the entered address and the registered card address.
In order to perform the AVS check on a transaction the billing_street and billing_zipcode must be populated in the request.

There are four possible results to the AVS check that will be returned in the avsaddress and avszipcode response parameters:

Response

Description

Comment

M

Matched

The information provided by the customer matches that on the card issuer’s records.
To replicate this response in QA pass "152 Aldgate Drive" in the "billing_street" parameter.
To replicate this response in QA pass "E1 7RT" in the "billing_zipcode" parameter.

N

Not Matched

The information provided by the customer does NOT match that on the card issuer’s records.
To replicate this response in QA pass "72 Aldgate Drive" in the "billing_street" parameter.
To replicate this response in QA pass "EW1 9HG" in the "billing_zipcode" parameter.

NC

Not Checked

Your acquirer was unable to perform this check on the information provided.
To replicate this response in QA pass "46 Aldgate Drive" in the "billing_street" parameter.
To replicate this response in QA pass "E8 4GT" in the "billing_zipcode" parameter.

NP

Not Provided

Your acquirer was not provided with the information required to perform this check.
To replicate this response in QA leave the "billing_street" parameter blank.
To replicate this response in QA leave the "billing_zipcode" parameter blank.

Response Codes

The table below details the current set of response codes and messages for the Acquired transaction API.

Code

Message

Comment

1

Transaction Success

11

Pending

101

Declined

102

Error:Invalid Parameters

103

Error:Invalid or Inactive MID Info

104

Error:Invalid or Unsupported Transaction Type

105

Error:Invalid or Unsupported Currency

106

Error:Invalid or Unsupported Card Type

107

Error:Incorrect Hash String

108

Blocked:Unauthorized Merchant IP Address

109

Error:Invalid timestamp

110

Error:Invalid merchant_order_id

111

Error:Invalid Company Info or Company Level Post Not Supported

112

Error:Can Not Find Qualified MID for Company Level Post

151

Blocked:Max MID Amount Reached

152

Blocked:Max MID Post Reached

153

Blocked:Max Monthly MID Reached

154

Blocked:Max Monthly MID Post Reached

155

Blocked:Max Daily MID Amount Reached

156

Blocked:Max Daily MID Post Reached

157

Blocked:Max Single MID Amount Reached

158

Blocked:Min Single MID Amount Not Reached

159

Blocked:Max Daily Refund Count Reached

160

Blocked:Max Daily Refund Amount Reached

161

Blocked:Max Montlhy Refund Count Reached

162

Blocked:Max Monthly Refund Amount Reached

170

Blocked:Max IP Daily Post

171

Blocked:Max IP Monthly Post

172

Blocked:Max Email Daily Post

173

Blocked:Max Email Monthly Post

174

Blocked:Max Phone Daily Post

175

Blocked:Max Phone Monthly Post

201

Error:Invalid cardnumber

202

Error:Card Type/Number Mismatch

203

Error:Invalid cardcvv

204

Error:Invalid or Expired cardexp

205

Error:Invalid cardholder_name

206

Error:Invalid billing_street

207

Error:Invalid billing_city

208

Error:Invalid billing_state

209

Error:Invalid billing_zipcode

210

Error:Invalid billing_country_code_iso2

211

Error:Invalid billing_phone

212

Error:Invalid_email

213

Error:Invalid_fname

214

Error:Invalid_lname

215

Error:Invalid Amount

216

Declined:Invalid AVS

217

Declined:Incorrect PIN

218

Declined:Payment Account Not Found

219

Error:Invalid customer_dob

220

Blocked:6012 Data Required

221

Error:Invalid shipping_street

222

Error:Invalid shipping_street2

223

Error:Invalid shipping_city

224

Error:Invalid shipping_state

225

Error:Invalid shipping_zipcode

226

Error:Invalid shipping_country_code_iso2

227

Error:Invalid shipping_phone

228

Error:Invalid shipping_email

229

Error:Invalid billing_street2

230

Error:Invalid customer_ipaddress

231

Error:Invalid subscription_type

232

Error: MID Does Not Support Subscription

233

Error:Original Tansaction Not Subscription or Not Approved

234

Error:Subscription Initialization Info Failed

235

Error:Subscription Info Retrieval Failed

236

Error:Subscription Info Update Failed

251

Declined:Fraudulent

252

Blocked:Card Blacklisted

253

Blocked:Phone Blacklisted

254

Blocked:Email Blacklisted

255

Blocked:IP Address Blacklisted

256

Blocked:BIN Blacklisted

257

Blocked:Fraud Risk Score Exceeded

258

Blocked:Fraud Check Unavailable

261

Error:Invalid Original Transaction ID, Type or Status

262

Error:Order ID Already Processed and/or Approved

263

Error:Original Transaction Already Settled, can not Void

264

Error:Original Transaction Not Settled Yet, can not Refund

265

Error:Original Transaction too old, can not Void, Capture or Refund

266

Error:Original Transaction Amount Exceeded for Refund

267

Error:Original Transaction Already Captured

268

Error:Original Transaction already Voided

269

Error:Original Transaction Not Found

270

Blocked:Max Refund Count Reached

271

Error:Original Transaction Already Refunded

272

Error:Capture Amount Greater Than Original Authed

273

Error:Partial Capture of Auth Not Allowed

274

Error:This Merchant Order ID is Being Processed

275

Blocked:Original Transaction Already ChargedBack

276

Error:Original Transaction is Being Updated

277

Blocked:Cancellation Requested

301

Declined:Insufficient Fund

302

Blocked:Max Amount Exceeded

303

Blocked:Max Transaction Exceeded

311

Blocked:Max Attempts Against Card Exceeded

312

Blocked:Max Attempts Authorised Card Exceeded

321

Declined:Revocation of Order by Cardholder

322

Blocked:Cardholder Cancellation

323

Declined:Restricted Card

324

Declined:CVV Failure

325

Declined:Card Expired

351

Blocked: 3DS Failed

401

Declined:Fraudulent

402

Declined:Lost or Stolen Card

403

Declined:Suspected Fraud

404

Declined: Fraudulent Bank Block

405

Blocked:BIN Filter

501

Pending:Card Enrolled

502

Pending:Card Not Enrolled

521

Blocked:3DS Invalid Action

522

Blocked:3Ds - Invalid PaRes

523

Blocked:3DS Invalid XID

524

Blocked:3DS Invalid CAVV

525

Blocked:3DS Not Active

526

Blocked:3DS Card Not Enrolled

527

Blocked:3DS Unable to Verify Enrolment

528

Blocked:3DS ACS URL Unavailable

529

Blocked:3DS Invalid Response

530

Blocked:3DS Password Failure

531

Blocked:3DS ACS Failure

532

Blocked:3DS Unavailable

533

Blocked:3DS Fatal Error

534

Blocked:3DS Original Transaction Not 3DS

901

System error

902

System error:Networking error

903

System error:HTTP error

904

System error:DB error

905

System error:Post to bank timeout

906

System error: Encryption failure

907

System error:Too Many Simultaneous Transactions

908

System error:Invalid response from bank

909

System error:Bank response Format Error

999

System Maintenance

Issuer Response Codes

An additional response parameter that Acquired can return to its merchants in real time is the ‘bank_response_code’, which is the actual transaction result code as communicated by the cardholder’s Issuing bank. Please contact us at [email protected] for further details on enabling this feature.

The table below details the current set of Issuer response codes including description of each.

Code

Message

Comment

00

Approved

01

Refer to card issuer

02

Refer to card issuer’s special conditions

03

Invalid merchant

04

Capture

05

Don’t honour

06

Unable to process transaction

07

Pick up card special condition

09

Duplicate transaction

11

Approved VIP

12

Invalid transaction

13

Invalid amount/ bad message edit

14

Invalid card number/no such number

15

No such issuer

17

Customer cancellation

18

Customer dispute

19

Re-enter transaction

20

Invalid response

21

No action taken

22

Suspected malfunction

23

Unacceptable transaction fee

26

Revocation of Auth Order

27

Revocation of All Auth Order

30

Format error

31

Bank not supported by switch

33

Expired card

34

Suspected fraud

35

Card Acceptor call acquirer security

36

Restricted card pick up

37

Capture

38

Pin tries exceeded

39

No credit account

40

Requested function not supported

41

Lost card

42

No universal account

43

Stolen card

44

No investment account

45 to 50

Error

51

Not sufficient funds

52

No cheque account

53

No savings account

54

Expired card

55

Incorrect PIN

56

No card record

57

Transaction not permitted by cardholder

58

Transaction not permitted by terminal

59

Suspected fraud

60

Card acceptor contact acquirer

61

Exceeds withdrawal amount limit

62

Restricted card

63

Security violation

64

Original amount incorrect

65

Exceeds withdrawal frequency limit

66

Card acceptor call acquirer’s security department

67

Hard capture

69 to 74

Error

85

Not declined. Valid for all 0 amount transactions

90

Unable to authorise

91

Issuer or switch is inoperative

92

Network problem

93

Transaction cannot be completed

94

Duplicate transmission

95

Reconcile error

96

System malfunction

97 to 99

Error

Chargeback Reason Codes

Code

Message

Comment

30

Services Not Provided or Goods Not Received

41

Cancelled Recurring Transaction

53

Not as Described or Defective Merchandise

57

Fraudulent Multiple Transactions

60

Illegible fulfillment

62

Counterfeit Transaction

70

Card Recovery Bulletin, Exception File

71

Declined Authorisation

72

No Authorisation

73

Expired Card

74

Late Presentment

75

Transaction Not Recognised

76

Incorrect Currency or Transaction Code

77

Non-Matching Account Number

78

Service Code Violation

80

Incorrect Transaction Amount or Account Number

81

Fraud-Card Present environment

82

Duplicate Processing

83

Fraud - Card Absent Environment

85

Credit Not Processed

86

Paid by Other Means

90

Non-Receipt of Cash / Load Transaction Value at ATM or Load Device

93

Merchant Fraud Performance Program

4802

Requested/Required Information Illegible or Missing

4807

Warning Bulletin File

4808

Requested/Required Authorization Not Obtained

4812

Account Number Not On File

4831

Transaction Amount Differs

4834

Duplicate Processing

4837

No Cardholder Authorization

4840

Fraudulent Processing of Transactions

4841

Cancelled Recurring Transaction

4842

Late Presentment

4846

Correct Transaction Currency Code Not Provided

4849

Questionable Merchant Activity

4850

Instalment Billing Dispute (Brazil Only)

4853

Cardholder Dispute - Defective Merchandise/Not As Described

4854

Cardholder Dispute - Not Elsewhere Classified (US Region Only)

4855

Goods or Services Not Provided

4859

Change to Addendum, No-Show, or ATM Dispute

4860

Credit Not Processed

4863

Cardholder Does Not Recognize - Potential

4870

Chip Liability Shift

4871

Chip/PIN Liability Shift

4999

Domestic Chargeback Dispute (Europe Region Only)

Country Codes

The table below lists the country code values used in the billing_country_iso2 parameter and the corresponding currency code used in the currency_code_iso3 parameter.

Country Name

Country Code

Currency Name

Currency Code

Numeric Code

Afghanistan

AF

Afghan Afghani

AFN

004

Ãland Islands

AX

Euro

EUR

248

Albania

AL

Albanian Lek

ALL

008

Algeria

DZ

Algerian Dinar

DZD

012

American Samoa

AS

United States Dollar

USD

016

Andorra

AD

Euro

EUR

020

Angola

AO

Angolan Kwanza

AOA

024

Anguilla

AI

Eastern Caribbean Dollar

XCD

660

Antigua and Barbuda

AG

Eastern Caribbean Dollar

XCD

028

Argentina

AR

Argentine Peso

ARS

032

Armenia

AM

Armenian Dram

AMD

051

Aruba

AW

Aruban Florin

AWG

533

Australia

AU

Australian Dollar

AUD

036

Austria

AT

Euro

EUR

040

Azerbaijan

AZ

Azerbaijani Manat

AZN

031

Bahamas

BS

Bahamian Dollar

BSD

044

Bahrain

BH

Bahraini Dinar

BHD

048

Bangladesh

BD

Bangladeshi Taka

BDT

050

Barbados

BB

Barbados Dollar

BBD

052

Belarus

BY

Belarusian Ruble

BYN

112

Belgium

BE

Euro

EUR

056

Belize

BZ

Belize Dollar

BZD

084

Benin

BJ

West African CFA Franc

XOF

204

Bermuda

BM

Bermudian Dollar (Customarily Known As Bermuda Dollar)

BMD

060

Bhutan

BT

Bhutanese Ngultrum

BTN

064

Bolivia, Plurinational State of

BO

Boliviano

BOB

068

Bonaire, Sint Eustatius and Saba

BQ

United States Dollar

USD

535

Bosnia and Herzegovina

BA

Bosnia And Herzegovina Convertible Mark

BAM

070

Botswana

BW

Botswana Pula

BWP

072

Bouvet Island

BV

Norwegian Krone

NOK

074

Brazil

BR

Brazillian Real

BRL

076

British Indian Ocean Territory

IO

United States Dollar

USD

086

Brunei Darussalam

BN

Brunei Dollar

BND

096

Bulgaria

BG

Bulgarian Lev

BGN

100

Burkina Faso

BF

West African CFA Franc

XOF

854

Burundi

BI

Burundian Franc

BIF

108

Cambodia

KH

Cambodian Riel

KHR

116

Cameroon

CM

Central African CFA Franc

CAF

120

Canada

CA

Canadian Dollar

CAD

124

Cape Verde

CV

Cape Verde Escudo

CVE

132

Cayman Islands

KY

Cayman Islands Dollar

KYD

136

Central African Republic

CF

Central African CFA Franc

CAF

140

Chad

TD

Central African CFA Franc

CAF

148

Chile

CL

Chilean Peso

CLP

152

China

CN

Chinese Yuan

CNY

156

Christmas Island

CX

Australian Dollar

AUD

162

Cocos (Keeling) Islands

CC

Australian Dollar

AUD

166

Colombia

CO

Colombian Peso

COP

170

Comoros

KM

Comorian Franc

COM

174

Congo

CG

Congolese Franc

CDF

178

Congo, the Democratic Republic of the

CD

Zairean Zaire

COD

180

Cook Islands

CK

New Zealand Dollar

NZD

184

Costa Rica

CR

Costa Rican Colon

CRC

188

Cote D Ivoire

CI

West African CFA Franc

XOF

384

Croatia

HR

Croatian Kuna

HRK

191

Cuba

CU

Cuban Peso

CUP

192

Curaçao

CW

Netherlands Antillean Guilder

ANG

531

Cyprus

CY

Euro

EUR

196

Czech Republic

CZ

Czech Koruna

CZK

203

Denmark

DK

Danish Krone

DKK

208

Djibouti

DJ

Djiboutian Franc

DJF

262

Dominica

DM

Eastern Caribbean Dollar

XCD

212

Dominican Republic

DO

Dominican Peso

DOP

214

Ecuador

EC

United States Dollar

USD

218

Egypt

EG

Egyptian Pound

EGP

818

El Salvador

SV

United States Dollar

USD

222

Equatorial Guinea

GQ

Central African CFA Franc

CAF

226

Eritrea

ER

Eritrean Nakfa

ERN

232

Estonia

EE

Euro

EUR

233

Ethiopia

ET

Ethiopian Birr

ETB

231

Falkland Islands (Malvinas)

FK

Falkland Islands Pound

FKP

238

Faroe Islands

FO

Danish Krone

DKK

234

Fiji

FJ

Fiji Dollar

FJD

242

Finland

FI

Euro

EUR

246

France

FR

Euro

EUR

250

French Guiana

GF

Euro

EUR

254

French Polynesia

PF

CFP Franc

XPF

258

French Southern Territories

TF

Euro

EUR

260

Gabon

GA

Central African CFA Franc

CAF

266

Gambia

GM

Gambian Dalasi

GMD

270

Georgia

GE

Georgian Lari

GEL

268

Germany

DE

Euro

EUR

276

Ghana

GH

Ghanaian Cedi

GHS

288

Gibraltar

GI

Gibraltar Pound

GIP

292

Greece

GR

Euro

EUR

300

Greenland

GL

Danish Krone

DKK

304

Grenada

GD

Eastern Caribbean Dollar

XCD

308

Guadeloupe

GP

Euro

EUR

312

Guam

GU

United States Dollar

USD

316

Guatemala

GT

Guatemalan Quetzal

GTQ

320

Guernsey

GG

Pound Sterling

GBP

831

Guinea

GN

Guinean Franc

GNF

324

Guinea-Bissau

GW

West African CFA Franc

XOF

624

Guyana

GY

Guyanese Dollar

GYD

328

Haiti

HT

Haitian Gourde

HTG

332

Holy See (Vatican City State)

VA

Euro

EUR

336

Honduras

HN

Honduran Lempira

HNL

340

Hong Kong

HK

Hong Kong Dollar

HKD

344

Hungary

HU

Hungarian Forint

HUF

348

Iceland

IS

Icelandic Kr–Na

ISK

352

India

IN

Indian Rupee

INR

356

Indonesia

ID

Indonesian Rupiah

IDR

360

Iran, Islamic Republic of

IR

Iranian Rial

IRR

364

Iraq

IQ

Iraqi Dinar

IQD

368

Ireland

IE

Euro

EUR

372

Isle of Man

IM

Pound Sterling

GBP

833

Israel

IL

Israeli New Sheqel

ILS

376

Italy

IT

Euro

EUR

380

Jamaica

JM

Jamaican Dollar

JMD

388

Japan

JP

Japanese Yen

JPY

392

Jersey

JE

Pound Sterling

GBP

832

Jordan

JO

Jordanian Dinar

JOD

400

Kazakhstan

KZ

Kazakhstani Tenge

KZT

398

Kenya

KE

Kenyan Shilling

KES

404

Kiribati

KI

Australian Dollar

AUD

296

Korea, Democratic People's Republic of

KP

North Korean Won

KPW

408

Korea, Republic of

KR

South Korean Won

KRW

410

Kosovo

XK

Euro

EUR

383

Kuwait

KW

Kuwaiti Dinar

KWD

414

Kyrgyzstan

KG

Kyrgyzstani Som

KGS

417

Lao People's Democratic Republic

LA

Lao Kip

LAK

418

Latvia

LV

Euro

EUR

428

Lebanon

LB

Lebanese Pound

LBP

422

Lesotho

LS

Lesotho Loti

LSL

426

Liberia

LR

Liberian Dollar

LRD

430

Libya

LY

Libyan Dinar

LYD

434

Liechtenstein

LI

Swiss Franc

CHF

438

Lithuania

LT

Euro

EUR

440

Luxembourg

LU

Euro

EUR

442

Macao

MO

Macanese Pataca

MOP

446

Macedonia, the former Yugoslav Republic of

MK

Macedonian Denar

MKD

807

Madagascar

MG

Malagasy Ariary

MGA

450

Malawi

MW

Malawian Kwacha

MWK

454

Malaysia

MY

Malaysian Ringgit

MYR

458

Maldives

MV

Maldivian Rufiyaa

MVR

462

Mali

ML

West African CFA Franc

XOF

466

Malta

MT

Euro

EUR

470

Marshall Islands

MH

United States Dollar

USD

584

Martinique

MQ

Euro

EUR

474

Mauritania

MR

Mauritanian Ouguiya

MRO

478

Mauritius

MU

Mauritian Rupee

MUR

480

Mayotte

YT

Euro

EUR

175

Mexico

MX

Mexican Peso

MXN

484

Micronesia, Federated States of

FM

United States Dollar

USD

583

Moldova, Republic of

MD

Moldovan Leu

MDL

498

Monaco

MC

Euro

EUR

492

Mongolia

MN

Mongolian Tugrik

MNT

496

Montenegro

ME

Euro

EUR

499

Montserrat

MS

Eastern Caribbean Dollar

XCD

500

Morocco

MA

Moroccan Dirham

MAD

504

Mozambique

MZ

Mozambican Metical

MZN

508

Myanmar

MM

Myanma Kyat

MMK

104

Namibia

NA

Namibian Dollar

NAD

516

Nauru

NR

Australian Dollar

AUD

520

Nepal

NP

Nepalese Rupee

NPR

524

Netherlands

NL

Euro

EUR

528

Netherlands Antilles

AN

Netherlands Antillean Guilder

ANG

599

New Caledonia

NC

CFP Franc

XPF

540

New Zealand

NZ

New Zealand Dollar

NZD

554

Nicaragua

NI

Nicaraguan C—Rdoba

NIO

558

Niger

NE

West African CFA Franc

XOF

562

Nigeria

NG

Nigerian Naira

NGN

566

Niue

NU

New Zealand Dollar

NZD

570

Norfolk Island

NF

Australian Dollar

AUD

574

Northern Mariana Islands

MP

United States Dollar

USD

580

Norway

NO

Norwegian Krone

NOK

578

Oman

OM

Omani Rial

OMR

512

Pakistan

PK

Pakistani Peso

PKR

586

Palau

PW

United States Dollar

USD

585

Panama

PA

Panamanian Balboa

PAB

591

Papua New Guinea

PG

Papua New Guinean Kina

PGK

598

Paraguay

PY

Paraguayan Guaranã­

PYG

600

Peru

PE

Peruvian Nuevo Sol

PEN

604

Philippines

PH

Philippine Peso

PHP

608

Pitcairn

PN

New Zealand Dollar

NZD

612

Poland

PL

Polish Zloty

PLN

616

Portugal

PT

Euro

EUR

620

Puerto Rico

PR

United States Dollar

USD

630

Qatar

QA

Qatari Riyal

QAR

634

Réunion

RE

Euro

EUR

638

Romania

RO

Romanian Leu

RON

642

Russian Federation

RU

Russian Rouble

RUB

643

Rwanda

RW

Rwandan Franc

RWF

646

Saint Helena, Ascension and Tristan da Cunha

SH

Saint Helena Pound

SHP

654

Saint Kitts and Nevis

KN

Eastern Caribbean Dollar

XCD

659

Saint Lucia

LC

Eastern Caribbean Dollar

XCD

662

Saint Martin (French part)

MF

Euro

EUR

663

Saint Pierre and Miquelon

PM

Euro

EUR

666

Saint Vincent and the Grenadines

VC

Eastern Caribbean Dollar

XCD

670

Samoa

WS

Samoan Tala

WST

882

San Marino

SM

Euro

EUR

674

Sao Tome and Principe

ST

Sao Tome And Principe Dobra

STD

678

Saudi Arabia

SA

Saudi Riyal

SAR

682

Senegal

SN

CFA Franc

XOF

686

Serbia

RS

Serbian Dinar

RSD

688

Seychelles

SC

Seychelles Rupee

SCR

690

Sierra Leone

SL

Sierra Leonean Leone

SLL

694

Singapore

SG

Singapore Dollar

SGD

702

Sint Maarten (Dutch part)

SX

Netherlands Antillean Guilder

ANG

534

Slovakia

SK

Euro

EUR

703

Slovenia

SI

Euro

EUR

705

Solomon Islands

SB

Solomon Islands Dollar

SBD

090

Somalia

SO

Somali Shilling

SOS

706

South Africa

ZA

South African Rand

ZAR

710

South Georgia and the South Sandwich Islands

GS

Pound Sterling

GBP

239

South Sudan

SS

South Sudanese Pound

SSP

728

Spain

ES

Euro

EUR

724

Sri Lanka

LK

Sri Lankan Rupee

LKR

144

Sudan

SD

Sudanese Pound

SGD

729

Suriname

SR

Surinamese Dollar

SRD

740

Svalbard and Jan Mayen

SJ

Norwegian Krone

NOK

744

Swaziland

SZ

Swazi Lilangeni

SZL

748

Sweden

SE

Swedish Krona/Kronor

SEK

752

Switzerland

CH

Swiss Franc

CHF

756

Syrian Arab Republic

SY

Syrian Pound

SYP

760

Taiwan, Province of China

TW

New Taiwan Dollar

TWD

158

Tajikistan

TJ

Tajikistani Somoni

TJS

762

Tanzania, United Republic of

TZ

Tanzanian Shilling

TZS

834

Thailand

TH

Thai Baht

THB

764

Timor-Leste

TL

United States Dollar

USD

626

Togo

TG

Cfa Franc

TGO

768

Tokelau

TK

New Zealand Dollar

NZD

772

Tonga

TO

Tongan Paanga

TOP

776

Trinidad and Tobago

TT

Trinidad And Tobago Dollar

TTD

780

Tunisia

TN

Tunisian Dinar

TND

788

Turkey

TR

Turkish Lira

TRY

792

Turkmenistan

TM

Turkmenistani Manat

TMT

795

Turks and Caicos Islands

TC

United States Dollar

USD

796

Tuvalu

TV

Tuvaluan Dollar

TVD

798

Uganda

UG

Ugandan Shilling

UGX

800

Ukraine

UA

Ukrainian Hryvnia

UAH

804

United Arab Emirates

AE

United Arab Emirates Dirham

AED

784

United Kingdom

GB

Pound Sterling

GBP

826

United States

US

United States Dollar

USD

840

United States Minor Outlying Islands

UM

United States Dollar

USD

581

Uruguay

UY

Uruguayan Peso

UYU

858

Uzbekistan

UZ

Uzbekistan Som

UZS

860

Vanuatu

VU

Vanuatu Vatu

VUV

548

Venezuela, Bolivarian Republic of

VE

Venezuelan Boliva

VEF

862

Viet Nam

VN

Viet Nam Dong

VND

704

Virgin Islands, British

VG

United States Dollar

USD

092

Virgin Islands, U.S.

VI

United States Dollar

USD

850

Wallis and Futuna

WF

CFP Franc

XPF

876

Western Sahara

EH

Moroccan Dirham

MAD

732

Yemen

YE

Yemeni Rial

YER

887

Zambia

ZM

Zambian Kwacha

ZMW

894

Zimbabwe

ZW

Zimbabwe Dollar

ZWD

716

Data Migration

Introduction

Acquired is committed to supporting data migration services. If you are new to Acquired we will import your existing sensitive cardholder data from your incumbent Payment Gateway. Acquired will also export your data should you ever choose to leave us.

Fees

For new merchants migrating data to Acquired the services will be provided without charge.

Should you ever choose to migrate data from Acquired to an alternative Payment Gateway there will be a small charge to cover project management and technical resourcing costs.

Time Frames

Whether importing or exporting data, you can expect all migrations to be executed within 5-10 business days.

Public Key

When migrating sensitive cardholder data to Acquired you will need to encrypt all files using Acquired's public key.

Importing Data

Acquired will work with you and your incumbent Payment Gateway to complete the data migration. The incumbent Payment Gateway will need to provide Acquired with an encrypted CSV file that includes at least the following fields:

Header

Description

ID

A unique ID representing the card / customer.

cardnumber

The credit/debit card number used for the transaction.

cardexp

The expiration date of the credit/debit card used for the transaction. Details to be submitted in the format MMYYYY.

You may need to send additional data beyond this to Acquired. For example, if you operate in the Financial Service sector you may have been assigned a Merchant Category Code (MCC) of '6012' by your Acquiring Bank. In this case, Visa requires you to capture additional data about your customers. It is mandated that this data be included within authorisation attempts for this MCC code. The additional MCC 6012 parameters are:

Header

Description

customer_lname

The customer's last name.

customer_dob

The customer's date of birth in YYYY-MM-DD format.

billing_zipcode

The cardholder's billing ZIP or postal code.

The Acquired Team will work with you to agree the best approach for you.

Upon successful completion of the data migration, Acquired will provide a file to you containing the token values of each card stored on your account.

Exporting Data

Before migrating your data to another Payment Gateway we must first verify that the provider is PCI compliant. Obtaining their valid Attestation of Compliance (AOC) will satisfy this requirement.

Once the AOC has been provided to Acquired, we will request a public encryption key from the receiving Payment Gateway. Acquired will then use this public key to encrypt the sensitive cardholder data and transmit it via SFTP.

Your sensitive cardholder data will be populated within a GPG encrypted CSV file. The file naming convention will be:

MERCHANTNAME_EXPORT_YYYY_MM_DD.CSV.GPG

The first row of the file will contain the headers as outlined in the below table. Each subsequent row will contain a new entry for each card that is tokenised on the Acquired Gateway.

Header

Description

transaction_id

The unique ID generated by Acquired for the transaction which also serves as the card token.

cardholder_name

The cardholder's name as printed on the card.

cardnumber

The credit/debit card number used for the transaction.

cardexp

The expiration date of the credit/debit card used for the transaction. Details to be submitted in the format MMYYYY.

Test Cards

Acquired has generated a set of test card numbers that will allow merchants to submit test transactions via Acquired’s dedicated Test environment. These test card numbers are to assist merchants during the integration process and are only valid within Acquired’s Test environment. Any attempt to process these cards in a Production environment will result in a declined response code.

The tables below provides a list of the Acquired test card numbers, the associated card type, along with the response codes and response messages generated for each card.