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.
Please contact [email protected] to gain access to the Acquired QA environment
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 API integration method offers merchants with enhanced security capabilities the ability to integrate directly into our low latency platform.

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.

Flexible
Style your payment page by uploading HTML, CSS, JavaScript, image and font files to our secure environment.
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.
Please see the below example:amount . company_id . company_mid_id . currency_code_iso3 . merchant_order_id . transaction_type //100.001331025GBP20170619111AUTH_CAPTURE
For a full list of parameters that must be included please see Request Parameters.
-
The resulting string must then be SHA256 encoded:
0722b76a63d0b7adde39b13119e4dfd5aa7bd0d91885d55597af334a055c4cd0
-
The “company hash” value needs to then be appended to the value generated in step 2 and once again SHA256 encoded:
0722b76a63d0b7adde39b13119e4dfd5aa7bd0d91885d55597af334a055c4cd0hashcode
934149504e39101f5cfad6ec3e971978890a057373ac3237e0dd150dd491d3d3
Please contact [email protected] to receive the company hash value.
Sample code for the creation of the hash value can be seen below:
<?php
$amount = "100.00";
$company_id = "133";
$company_mid_id = "1025";
$currency_code_iso3 = "GBP";
$merchant_order_id = "20160907_111";
$transaction_type = "AUTH_ONLY";
$company_hash = "hashcode";
$tmp = $amount . $company_id . $company_mid_id . $currency_code_iso3 . $merchant_order_id . $transaction_type . "";
//$tmp = 100.001331025GBP20160907_111AUTH_ONLY;
$tmp2 = hash ("sha256" , $tmp);
//$tmp2 = b9646f814518a42e74f0a5cc2438881ec4dfc7f6f7ce39471e13a5a1c262c262;
$tmp3 = $tmp2 . $company_hash . "";
//$tmp3 = b9646f814518a42e74f0a5cc2438881ec4dfc7f6f7ce39471e13a5a1c262c262hashcode;
$hash = hash ("sha256" , $tmp3);
$hash = "6da23f6be1a2ea1d2a7687c6a84d0d7e3213c56915f9768bc5f74d5e6f968775";
?>
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:
<!DOCTYPE html>
<html>
<head>
<title>Sample Code</title>
</head>
<body>
<form action="https://qahpp.acquired.com" method="POST">
<input type=hidden name="company_id" value="133">
<input type=hidden name="company_mid_id" value="1025">
<input type=hidden name="currency_code_iso3" value="GBP">
<input type=hidden name="transaction_type" value="AUTH_ONLY">
<input type=hidden name="merchant_order_id" value="20160907_111">
<input type=hidden name="amount" value="100.00">
<input type=hidden name="hash" value="6da23f6be1a2ea1d2a7687c6a84d0d7e3213c56915f9768bc5f74d5e6f968775">
<input type=submit value="Submit">
</form>
</body>
</html>
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).
PARAMETER | FORMAT | LENGTH | DESCRIPTION |
---|---|---|---|
company_id Required | int 0-9 | 1-4 | API Company ID issued by Acquired to the merchant. |
company_mid_id Required | int 0-9 | 1-11 | API MID ID issued by Acquired to the merchant. |
hash Required | string 0-9 a-z A-z _ - | 65 | Security hash value. Please see here. |
vt | boolean 0 / 1 | 1 | Additional parameter to flag a transaction as MOTO. Should be included if process payments over the phone or via an IVR solution. |
merchant_order_id Required | string a-z A-Z 0-9 _ - | 1-50 | The unique ID used by the merchant to identify the transaction. |
transaction_type Required | string a-z A-Z _ | 1-20 | The transaction type being performed. |
currency_code_iso3 Required | string a-z A-Z | 3 | The ISO 4217 3-digit currency code of the currency used in the transaction. |
amount Required | string 0-9 in the format DDDDDD.CC | 1-11 | The amount of the transaction. |
is_tds 3-D Secure | boolean 0 / 1 | 1 | Flag to enable 3-D Secure authentication check. |
merchant_customer_id | string a-z A-Z 0-9 , . - _ | 0-50 | The unique customer ID used by the merchant to identify the customer. |
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. |
customer_title | string a-z A-Z , . - _ | 0-20 | The customer’s title such as Mr. or Mrs. |
customer_fname | string a-z A-Z , . - _ | 0-50 | The customer’s first name. |
customer_mname | string a-z A-Z , . - _ | 0-50 | The customer’s middle name. |
customer_lname MCC 6012 | string a-z A-Z , . - _ | 0-50 | The customer’s last 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_dob MCC 6012 | string 0-9 in the format YYYY-MM-DD | 10 | The customer’s date of birth in YYYY-MM-DD format. |
customer_company | string a-z A-Z 0-9 , . - _ | 0-50 | The customer’s company. |
billing_street AVS | 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_city | string a-z A-Z 0-9 , . - _ | 1-100 | The city of the cardholder’s address. |
billing_state | string a-z A-Z 0-9 , . - _ | 1-100 | The state or province of the cardholder’s address. |
billing_zipcode MCC 6012 & AVS | string a-z A-Z 0-9 , . - _ | 1-50 | The cardholder’s billing ZIP or postal code. |
billing_country_code_iso2 | string a-z A-Z | 2 | The ISO 3166 2-character country code of the cardholder’s address. Refer to ‘Country Code v1.0.pdf’ for full list of valid Country Codes. |
billing_phone | string 0-9 ( ) + - | 7-20 | The cardholder’s billing phone number. |
billing_email | string 0-9 a-z A-z _ - . @ | 1-50 | The cardholder’s billing email address. |
callback_url | string 0-9 a-z A-z - . _ ~ : / ? # [ ] @ ! $ & ' ( ) * + , ; = ` . | 10-2083 | Direct server-to-server feedback, please see here for more information. Will overwrite default value configured in the Acquired portal. |
return_url | string 0-9 a-z A-z - . _ ~ : / ? # [ ] @ ! $ & ' ( ) * + , ; = ` . | 10-2083 | Used to redirect customers from the Acquired environment back to the merchants website following the authorisation. Will overwrite default value configured in the Acquired portal. |
error_url | string 0-9 a-z A-z - . _ ~ : / ? # [ ] @ ! $ & ' ( ) * + , ; = ` . | 10-2083 | User will be redirected back to this URL in the event of an error. Acquired will send back the following parameters: status, message, company_id, company_mid_id and merchant_order_id. |
template_id | int 0-9 | 4-10 | Please see here. |
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.
Please note that the returnurl parameter must always begin with https:// and should be configured to handle all possible transaction response codes including errors.
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.
Please note that the callbackurl parameter must always begin with https:// and should be configured to handle all possible transaction response codes including errors
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.
Please see the below example:amount . cardnumber . code . message . merchant_order_id . transaction_id //100.00XXXX-XXXX-XXXX-12341Transaction Success20160907_111123456
For a full list of parameters that may be included please see Response Parameters.
-
The resulting string must then be SHA256 encoded:
b51f1cbbdc59d5018eaaaac094a1cce2ad4c8dd274898e0a61ea452037004e0b
-
The “mid_hash” value needs to then be appended to the value generated in step 2 and once again SHA256 encoded:
b51f1cbbdc59d5018eaaaac094a1cce2ad4c8dd274898e0a61ea452037004e0bcmidhash
518b9069923ca211222cb8d298482320b1e2458b4228f335553a4ee22812e035
Please contact [email protected] to receive the mid_hash value.
Please see the below PHP sample code as an example of how to calculate the response hash:
<?php
$company_hash = "hashcode";
$hash = $_POST["hash"];
$post = $_POST;
unset($post["hash"]);
ksort($post);
$tmp = implode(" ", $post);
$tmp2 = hash("sha256", $tmp);
?>
Response Parameters
PARAMETER | FORMAT | LENGTH | DESCRIPTION |
---|---|---|---|
amount | string 0-9 | 1-11 | The amount of the transaction. |
avsaddress | string a-z A-Z | 1-2 | When available the result of the AVS check on the first line of the address. |
avszipcode | string a-z A-Z | 1-2 | When available the result of the AVS check on the customer’s postcode / zipcode. |
bank_response_code | int 0-9 | 2 | The transaction result code as communicated by the Issuing Bank. |
bin | int 0-9 | 6 | The first 6 characters of the card used for the transaction. |
card_category | string a-z A-Z | 0-30 | The category of the card used. For example CREDIT / DEBIT. |
card_level | string a-z A-Z | 0-30 | The level of the card used. For example CLASSIC. |
card_type | string a-z A-Z | 2-8 | The type of debit/credit card used for the transaction. |
cardexp | int 0-9 in the format MMYYYY | 6 | The expiration date of the credit/debit card used for the transaction. |
cardholder_name | string a-z A-Z , . - _ | 1-100 | The cardholder’s name as entered into the HPP |
cardnumber | int 0-9 | 12-19 | The masked credit/debit card number used for the transaction. |
code | int 0-9 | 1-3 | The code describing the results of the transaction. |
company_id | int 0-9 | 1-4 | API Company ID issued by Acquired to the merchant. |
company_mid_id | int 0-9 | 1-11 | API MID ID issued by Acquired to the merchant. |
eci | int 0-9 | 1-4 | Result of the 3-D Secure authentication. |
cvvresult | string a-z A-Z | 1-2 | The result of the CVV2 security check. |
is_remember | boolean 0 / 1 | 1 | Flag to indicate if the card details have been tokenised by Acquired for future use. |
issuing_bank | string a-z A-Z . | 0=50 | The name of the bank the issued the card used. |
issuing_country | string a-z A-Z | 0-50 | The country the issued the card. |
issuing_country_iso2 | string a-z A-Z | 0-50 | The ISO2 country code for the country that issued the card. |
merchant_order_id | string a-z A-Z 0-9 - _ | 1-50 | The unique ID used by the merchant to identify the transaction. This echoes the merchant_order_id from the request message. |
message | string 0-9 a-z A-z _ - ()[]{};[email protected]#$%^*,./\?:”’ +=` | 1-65535 | Text describing the transaction response. |
transaction_id | int 0-9 | 1-10 | The unique ID generated by Acquired for the transaction. |
hash | string a-z A-Z 0-9 | 64 | A verification hash value. |
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:
<form method="post" action="{{settlement_url}}" data-oldid="{{original_transaction_id}}">
<input type="hidden" name="hpp_id" value="{{hpp_id}}">
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.
Contact [email protected] to enable subscription features on your account.
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.
Please see the example below of a INIT account verification request:
{
"timestamp":"20170612200234",
"company_id":"133",
"company_pass":"password ",
"company_mid_id":"",
"request_hash":"f0a18260b08a0bfacb...",
"transaction":{
"merchant_order_id":"20170612200234",
"transaction_type":"AUTH_ONLY",
"subscription_type":"INIT",
"amount":"0",
"currency_code_iso3":"GBP",
"merchant_customer_id":"100000087",
"merchant_custom_1":"C1",
"merchant_custom_2":"C2",
"merchant_custom_3":"C3"
} ,
"customer":{
"customer_title":"Mr.",
"customer_fname":"Edward",
"customer_mname":"N",
"customer_lname":"Johnson",
"customer_gender":"M",
"customer_dob":"1988-12-14",
"customer_ipaddress":"2a02:d7f:c401:5f00:7538:fbfc:4a41:e3d2 ",
"customer_company":"Acquired Payments"
} ,
"billing":{
"cardholder_name":"MR E N JOHNSON",
"cardnumber":"4242424242424242",
"card_type":"VISA",
"cardcvv":"123",
"cardexp":"022020",
"billing_street":"44 Baker Street",
"billing_street2":"",
"billing_city":"London",
"billing_state":"",
"billing_zipcode":"W1U 7AL",
"billing_country_code_iso2":"GB",
"billing_phone":"+44 (0) 7763270200",
"billing_email":"[email protected]"
} ,
}
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.
Please see the example below of a REBILL authorisation request:
{
"timestamp":"20170612200234",
"company_id":"133",
"company_pass":"password",
"company_mid_id":"",
"request_hash":"f0a18260b08a0bfacb...",
"transaction":{
"merchant_order_id":"20170612200234",
"transaction_type":"AUTH_ONLY",
"original_transaction_id":"1234567",
"subscription_type":"REBILL",
"amount":"100",
"currency_code_iso3":"GBP"
} ,
}
REBILL Request Parameters
The rebill operation requires two additional parameters than regular AUTH_ONLY and AUTH_CAPTURE transaction types:
PARAMETER | FORMAT | LENGTH | DESCRIPTION |
---|---|---|---|
subscription_type | string a-Z A-Z _ |
4 - 14 | 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:
{
"timestamp":"20170612200234",
"company_id":"133",
"company_pass":"password",
"company_mid_id":"",
"request_hash":"f0a18260b08a0bfacb...",
"transaction":{
"merchant_order_id":"20170612200234",
"transaction_type":"AUTH_ONLY",
"original_transaction_id":"1234567",
"subscription_type":"REUSE",
"amount":"100",
"currency_code_iso3":"GBP"
},
"billing":{
"cardcvv":"123"
},
"tds":{
"action":"ENQUIRE"
},
}
Note that for the REUSE operation it is possible to include both CVV and 3-D Secure details but both are optional.
By using REUSE instead of the REBILL operation we'll pass onto the card schemes / issuer that the cardholder is present on your website when the payment is initiated.
To continue with implementing 3-D Secure as part of this request type please see here. The ENQUIRE response will be the same format and it will follow the same process.
The response is the same as a regular authorisation transaction type which can be found here.
UPDATE_BILLING
In order to update the billing details for an existing INIT for future REBILL transactions use UPDATE_BILLING in the "subscription_type" parameter of the authorisation request.
Please see the example of a UPDATE_BILLING authorisation request:
{
"timestamp":"20170612200234",
"company_id":"133",
"company_pass":"password ",
"company_mid_id":"",
"request_hash":"f0a18260b08a0bfacb...",
"transaction":{
"merchant_order_id":"20170612200234",
"transaction_type":"AUTH_CAPTURE",
"original_transaction_id":"1234567",
"subscription_type":"UPDATE_BILLING",
"amount":"100",
"currency_code_iso3":"GBP"
} ,
"billing":{
"cardholder_name":"MR E N JOHNSON",
"cardnumber":"4024007164218280",
"card_type":"VISA",
"cardcvv":"456",
"cardexp":"032022"
} ,
}
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
Please contact [email protected] to activate 3-D Secure on your account.
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
{
"timestamp":"20170612200234",
"company_id":"133 ",
"company_mid_id":" ",
"company_pass":"password ",
"request_hash":"f0a18260b08a0bfacb...",
"transaction":{
"merchant_order_id":"20170612200234",
"transaction_type":"AUTH_ONLY",
"original_transaction_id":"",
"subscription_type":"",
"amount":"100",
"currency_code_iso3":"GBP",
"merchant_customer_id":"100000087",
"merchant_custom_1":"C1",
"merchant_custom_2":"C2",
"merchant_custom_3":"C3"
} ,
"customer":{
"customer_title":"Mr.",
"customer_fname":"Edward",
"customer_mname":"N",
"customer_lname":"Johnson",
"customer_gender":"M",
"customer_dob":"1988-12-14",
"customer_ipaddress":"2a02:d7f:c401:5f00:7538:fbfc:4a41:e3d2 ",
"customer_company":"Acquired Payments"
} ,
"billing":{
"cardholder_name":"MR E N JOHNSON",
"cardnumber":"4242424242424242",
"card_type":"VISA",
"cardcvv":"123",
"cardexp":"022020",
"billing_street":"44 Baker Street",
"billing_street2":"",
"billing_city":"London",
"billing_state":"",
"billing_zipcode":"W1U 7AL",
"billing_country_code_iso2":"GB",
"billing_phone":"+44 (0) 7763270200",
"billing_email":"[email protected]"
} ,
"tds":{
"action":"ENQUIRE"
} ,
}
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 | ||
action Required |
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:
{
"timestamp":"20170612200234",
"response_code":"501",
"response_message":"Pending:Card Enrolled",
"company_id":"133",
"mid":"1025",
"transaction_id":"1234567",
"transaction_type":"AUTH_ONLY",
"merchant_order_id":"20170612200234",
"amount":"100",
"currency_code_iso3":"GBP",
"authorisation_code":"",
"acquirer_reference_number":"",
"bank_response_code":""
"tds":{
"pareq":"eJxVkd1SgzAQhe99CoZ7m5+mCXS26dQ6js6o49jqPYSloAJtAG3f3qRSq1ztx+6e3ZyF+b76CD7Rt......",
"url":"https://www.securesuite.com/bank/tdsecure/opt_in_dispatcher.jsp?partner=bank.visa&VAA=B",
"enrolled":"Y"
} ,
"bin":{
"issuing_bank":"JP MORGAN CHASE NA",
"card_category":"CREDIT",
"card_level":"",
"issuing_country":"United States",
"issuing_country_iso2":"US"
},
"response_hash":"835956a9fe56d65416....."
}
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 enrolled N: Cardholder not enrolled U 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.
"enrolled":'U / Blank' Unable to verify enrollement, decline transaction.
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.
<!DOCTYPE html>
<html>
<head>
<title>3-D Secure – ACS Redirect</title>
<script type=”text/javascript”>
function OnLoadEvent() {
document.form.submit();
}
</script>
</head>
<body onload=”OnLoadEvent()”>
<form action=”https://qaacs.acquired.com/” method=”POST”>
<input type=”hidden” name=”PaReq” value=”eJxVkd1SgzAQhe99CoZ7m5+mCXS26dQ6js6o49jqPYSloAJtAG3f3qRSq1ztx+6e3ZyF+b76CD7Rt......”>
<input type=”hidden” name=”TermUrl” value=”https://www.yourwebsite.com/termurl”>
<input type=”hidden” name=”MD” value=”434irjfewiofk………”>
<noscript>
<input type=”submit”/>
</noscript>
</form>
</body>
</html>
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:
|
Response Parameters
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.
The following is an example of a SETTLEMENT request:
{
"timestamp":"20170612200254",
"company_id":"133 ",
"company_mid_id":" ",
"company_pass":"password ",
"request_hash":"km78ks767db39gne012e1960s...",
"transaction":{
"merchant_order_id":"20170612200234",
"transaction_type":"AUTH_ONLY",
"original_transaction_id":"1234567",
"subscription_type":"",
"amount":"100",
"currency_code_iso3":"GBP"
} ,
"tds":{
"action":"SETTLEMENT",
"pares":"3290uif32ijf…………"
} ,
}
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:
PARAMETER | FORMAT | LENGTH | DESCRIPTION |
---|---|---|---|
tds | object | ||
action Required |
string a-Z A-Z |
7-10 | Value should be set to SETTLEMENT. |
pares Required |
string Base64 encoded |
1-2000 | Pares value returned from the POST to ACS. |
SETTLEMENT Response Parameters
The following is an example of an AUTH_ONLY SETTLEMENT transaction response where the cardholder has successfully authenticated themselves:
{
"timestamp":"20170612200234",
"response_code":"1",
"response_message":"Transaction Success",
"company_id":"133",
"mid":"1025",
"transaction_id":"1234567",
"transaction_type":"AUTH_ONLY",
"merchant_order_id":"20170612200234",
"amount":"100",
"currency_code_iso3":"GBP",
"authorisation_code":"724695",
"acquirer_reference_number":"",
"avsaddress":"M",
"avszipcode":"M",
"cvvresult":"M",
"bank_response_code":"85"
"bin":{
"issuing_bank":"JP MORGAN CHASE NA",
"card_category":"CREDIT",
"card_level":"",
"issuing_country":"United States",
"issuing_country_iso2":"US"
},
"tds":{
"status":"Y",
"eci":"5"
},
"response_hash":"835956a9fe56d65416....."
}
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. U: Cardholder authentication temporarily unavailable - no liability shift available. |
eci | int 0-9 |
1 | The e-commerce indicator. |
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:
{
"timestamp":"20170612200234",
"company_id":"133 ",
"company_mid_id":" ",
"company_pass":"password ",
"request_hash":"f0a18260b08a0bfacb...",
"transaction":{
"merchant_order_id":"20170612200234",
"transaction_type":"AUTH_ONLY",
"amount":"100",
"currency_code_iso3":"GBP"
},
"billing":{
"cardholder_name":"MR E N JOHNSON",
"cardnumber":"4242424242424242",
"card_type":"VISA",
"cardcvv":"123",
"cardexp":"022020"
},
"tds":{
"action":"EXTERNAL",
"cavv":"jD/jxYfZUTcFCBAAABrGBjUAAAA=",
"xid":"WSwj8tn6OMRiahoMk+lN1fotqd0=",
"eci":"5",
"status":"Y",
"enrolled":"Y"
},
}
The following table describes these additional request parameters:
PARAMETER | FORMAT | LENGTH | DESCRIPTION |
---|---|---|---|
tds | object | ||
action | string a-z A-Z |
1 | Should be set to EXTERNAL. |
cavv | string 0-9 a-z A-z _ - ()[]{};[email protected]#$%^*,./\?:”’ += |
1 | The Cardholder Authentication Verification Value, a unique value confirming the customer’s authentication status. |
xid | string 0-9 a-z A-z _ - ()[]{};[email protected]#$%^*,./\?:”’ += |
1 | A unique ID for the 3D Secure transaction. |
eci | int 0-9 |
1 | The e-commerce indicator. | 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. U: Cardholder authentication temporarily unavailable - no liability shift available. |
enrolled | string a-z A-Z |
1 | Confirmation if the card was enrolled (Y) or not enrolled (N). |
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.
function sha256hash_status($param,$secret){
if(in_array($param['status_request_type'],array('ORDER_ID_ALL','ORDER_ID_FIRST','ORDER_ID_LAST','ORDER_ID_SUCCESS'))){
$str=$param['timestamp'].$param['status_request_type'].$_id.$param['merchant_order_id'];
}elseif(in_array($param['status_request_type'],array('TRANSACTION_ID','TRANSACTION_ID_CHILDREN_ALL','TRANSACTION_ID_CHILDREN_FIRST','TRANSACTION_ID_CHILDREN_LAST','TRANSACTION_ID_CHILDREN_SUCCESS'))){
$str=$param['timestamp'].$param['status_request_type'].$param['company_id'].$param['transaction_id'];
}elseif(in_array($param['status_request_type'],array('BIN'))){
$str=$param['timestamp'].$param['status_request_type'].$param['company_id'].$param['bin'];
}
return hash('sha256',$str.$secret);
}
public String statusRequestHash(Map param, String secret) throws Exception {
String str = “”;
String status_request_type = param.get(“status_request_type”);
String[] status_request_type_order = {“ORDER_ID_ALL”,“ORDER_ID_FIRST”,“ORDER_ID_LAST”,“ORDER_ID_SUCCESS”};
String[] status_request_type_transaction = {“TRANSACTION_ID”,“TRANSACTION_ID_CHILDREN_ALL”,“TRANSACTION_ID_CHILDREN_FIRST”,“TRANSACTION_ID_CHILDREN_LAST”,“TRANSACTION_ID_CHILDREN_SUCCESS”};
String[] status_request_type_bin = {“BIN”};
if(Arrays.asList(status_request_type_order).contains(status_request_type)) {
str = param.get(“timestamp”) + param.get(“status_request_type”) + param.get(“company_id”) + param.get(“merchant_order_id”);
}else if(Arrays.asList(status_request_type_transaction).contains(“transaction_type”)){
str = param.get(“timestamp”) + param.get(“status_request_type”) + param.get(“company_id”) + param.get(“transaction_id”);
}else if(Arrays.asList(status_request_type_bin).contains(“transaction_type”)){
str = param.get(“timestamp”) + param.get(“status_request_type”) + param.get(“company_id”) + param.get(“bin”);
}
String secstr = str + secret;
return sha256hash(secstr);
}
public String StatusRequestHash(Hashtable param, String secret)
{
string str = “”;
string status_request_type = param[“status_request_type”].ToString();
string[] status_request_type_order = { “ORDER_ID_ALL”,“ORDER_ID_FIRST”,“ORDER_ID_LAST”,“ORDER_ID_SUCCESS”};
string[] status_request_type_transaction = { “TRANSACTION_ID”, “TRANSACTION_ID_CHILDREN_ALL”, “TRANSACTION_ID_CHILDREN_FIRST”, “TRANSACTION_ID_CHILDREN_LAST”, “TRANSACTION_ID_CHILDREN_SUCCESS” };
string[] status_request_type_bin = { “BIN” };
if (Array.IndexOf(status_request_type_order, status_request_type) != -1)
{
str = param[“timestamp”].ToString() + param[“status_request_type”].ToString() + param[“company_id”].ToString() + param[“merchant_order_id”].ToString();
}
else if (Array.IndexOf(status_request_type_transaction, status_request_type) != -1)
{
str = param[“timestamp”].ToString() + param[“status_request_type”].ToString() + param[“company_id”].ToString() + param[“transaction_id”].ToString();
}
else if (Array.IndexOf(status_request_type_bin, status_request_type) != -1)
{
str = param[“timestamp”].ToString() + param[“status_request_type”].ToString() + param[“company_id”].ToString() + param[“bin”].ToString();
}
string secstr = str + secret;
return Sha256hash(secstr);
}
Request Examples
Below is an example JSON request for the "BIN", "TRANSACTION_ID_SUCCESS" and "ORDER_ID_ALL" status_request_types.
Please see here for more information on these parameters.
"company_id":"133",
"company_pass":"password ",
"request_hash":"d98wd34349d23034fe..... ",
"transaction":{
"bin":"424242"
},
"company_id":"133",
"company_pass":"password ",
"request_hash":"ffs934d87d3240dw32..... ",
"transaction":{
"transaction_id":"138210"
},
"company_id":"133",
"company_pass":"password ",
"request_hash":"vdrv342487dsclelvs..... ",
"transaction":{
"transaction_id":"20180306211733"
},
Response Examples
Below is the corresponding JSON responses for the request examples shown above. Please see here for more information on these parameters.
Please note: in the event of an error we will respond with "result_code":"-1".
"company_id":"133",
"result_code":"1 ",
"result_message":"Success",
"response_hash":"",
"bin":{
"card_category":"CREDIT",
"card_level":"STANDARD",
"issuing_country":"United States",
"issuing_country_iso2":"US"
},
"company_id":"133",
"result_code":"1 ",
"result_message":"Success",
"response_hash":"",
"total_transaction":"2",
"transaction": [ {
"response_code":"1",
"response_message":"Transaction Success ",
"transaction_id":"138756",
"transaction_type":"AUTH_CAPTURE",
"merchant_order_id":"20180306211733",
"amount":"100.00",
"currency_code_iso3":"GBP",
"authorisation_code":"123456",
"acquirer_reference_number":"{}",
"transaction_datetime":"2018-03-06 21:17:51",
"bin":{
"card_category":"CREDIT",
"card_level":"STANDARD",
"issuing_country":"United States",
"issuing_country_iso2":"US"
},
{
"mid":"1045",
"response_code":"1",
"response_message":"Transaction Success ",
"transaction_id":"138396",
"transaction_type":"AUTH_CAPTURE",
"merchant_order_id":"20180215153938-538",
"amount":"175.00",
"currency_code_iso3":"GBP",
"authorisation_code":"654321",
"acquirer_reference_number":"{}",
"transaction_datetime":"2018-02-15 15:39:38",
"bin":{
"card_category":"CREDIT",
"card_level":"STANDARD",
"issuing_country":"United States",
"issuing_country_iso2":"US"
}
} ]
"company_id":"133",
"result_code":"1 ",
"result_message":"Success",
"response_hash":"",
"total_transaction":"1",
"transaction": [ {
"response_code":"1",
"response_message":"Transaction Success ",
"transaction_id":"138756",
"transaction_type":"AUTH_CAPTURE",
"merchant_order_id":"20180306211733",
"amount":"100.00",
"currency_code_iso3":"GBP",
"authorisation_code":"123456",
"acquirer_reference_number":"{}",
"transaction_datetime":"2018-03-06 21:17:51",
"bin":{
"card_category":"CREDIT",
"card_level":"STANDARD",
"issuing_country":"United States",
"issuing_country_iso2":"US"
}
}
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.
AAAAB3NzaC1kc3MAAACBAPosdQoxSsbr/p4BUffJI48Nqfl2724T5gFtT7vEIeSkOzwyp+/lWbpidKpHFBsn5OejTD9TzQCaFPitQkVuP0zgAF6nO6h3tKl57i0
jtcdVahfG/HfLv7Cd07/7VPFntTOxzI1HgcKsN3qvTmaTiTEmEiypH7eAK/NTXCekp663AAAAFQDTAKUnP3gx9FF2nIR0OPaIfsGa6QAAAIAi5U4HuPcGtAo0yp
nzfag2Ht6m5Bpue2nUIesoU0DESh1SksOfxOPIaGayOrztWvFuWUm0Vvg4HYF4LjHNP/+6jdc4lmjjZt+4khx0xN0Vq6/uU2XZOZGq6UNj2iW9Cb8njVdw2EvUD
c9pxSpd8sEdQULia/Knb4RjFgngKCsj5QAAAIAcS8WOcBIf3t8zd6XMiCsO6YsTDDbZYxnv1Nx2NFZrUOlniRgBcmuoOifk99BiCbx64OoUqT8+6ZCpBdebr/uZ
QANRIBR9tLEwUfJO/TCNqu7LSP5yk/RY5OumUnfdzytTnHWWSWeFbbPYRfI66gYO0AJL14L/dXSWk2sFxhxh6w==
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:
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.
Visa
Cardnumber | Card Type | Code | Message |
---|---|---|---|
4024007164218280 | VISA | 1 | Transaction Success |
4532289650235755 | VISA | 101 | Declined |
4916431398519886 | VISA | 106 | Declined: Invalid or unsupported card type |
4485867369727274 | VISA | 110 | Declined: Invalid order id |
4916245230329217 | VISA | 201 | Declined: Invalid card number |
4539018641369339 | VISA | 203 | Declined: Invalid card cvv |
4539505836256479 | VISA | 251 | Declined: Fraudulent |
4532060334295535 | VISA | 263 | Declined: Original Transaction already settled, can not VOID |
4716187343712172 | VISA | 264 | Declined: Original Transaction was not settled yet, can not REFUND |
4716874255910825 | VISA | 301 | Declined: Insufficient fund |
4073603925073129 | VISA | 321 | Declined: Revocation of order by Cardholder |
4716046492169586 | VISA | 402 | Declined: Lost or stolen card |
4743189337667120 | VISA | 901 | System error |
MasterCard
Cardnumber | Card Type | Code | Message |
---|---|---|---|
5334099499911681 | MC | 1 | Transaction Success |
5158177814255696 | MC | 101 | Declined |
5206557941304537 | MC | 106 | Declined: Invalid or unsupported card type |
5144636304557108 | MC | 110 | Declined: Invalid order id |
5244110690114154 | MC | 201 | Declined: Invalid card number |
5111876826144400 | MC | 203 | Declined: Invalid card cvv |
5415106210369834 | MC | 251 | Declined: Fraudulent |
5421023486889738 | MC | 263 | Declined: Original Transaction already settled, can not VOID |
5494705174909669 | MC | 264 | Declined: Original Transaction was not settled yet, can not REFUND |
5305145611714597 | MC | 301 | Declined: Insufficient fund |
5435464107581094 | MC | 321 | Declined: Revocation of order by Cardholder |
5110514319494395 | MC | 402 | Declined: Lost or stolen card |
5264046163248019 | MC | 901 | System error |
3-D Secure
Cardnumber | Card Type | Code | Message |
---|---|---|---|
4485600864021418 | VISA | 501 | Pending:Card enrolled |
4716377587922807 | VISA | 502 | Pending:Card not enrolled but url avaiable |
4556179602266787 | VISA | 526 | Declined:3Ds - Card not enrolled and url unavailable |
4024007159369015 | VISA | 527 | Declined:3Ds - Card not sure enrolled or not, and url unavailable |
4916667674635868 | VISA | 528 | Declined:3Ds - Card not enrolled |
4485624228918044 | VISA | 529 | Declined:3Ds - Card not sure enrolled or not |
4916387123582195 | VISA | 530 | Declined:3Ds - Issuer Bank auth failed |
4024007125657444 | VISA | 531 | Declined:3Ds - Decryption failed |