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.



API

API

The Acquired API integration method offers merchants with enhanced security capabilities the ability to integrate directly into our low latency platform.

HPP

Hosted Payment Page

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

PCI DSS

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


Devices

Templates

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

Devices

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:

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

  2. The resulting string must then be SHA256 encoded:

    0722b76a63d0b7adde39b13119e4dfd5aa7bd0d91885d55597af334a055c4cd0

  3. 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
int 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.

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:

  1. Customer’s closing their browser before being redirected back to the merchant
  2. Temporary connection issues with merchants servers
  3. 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.

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

  2. The resulting string must then be SHA256 encoded:

    b51f1cbbdc59d5018eaaaac094a1cce2ad4c8dd274898e0a61ea452037004e0b

  3. 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
int 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:

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

  2. REBILL: Used to make subsequent charge of existing subscriptions.

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

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

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

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

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

  2. 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://www.securesuite.com/bank/tdsecure/opt_in_dispatcher.jsp?partner=bank.visa&VAA=B” 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
string a-z A-Z 0-9 ' " . , - _ / : = ?
1-2000 The encoded pareq you received from Acquired.
TermUrl
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
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.

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.

{
"timestamp":"20170612200224",
"company_id":"133",
"company_pass":"password ",
"request_hash":"d98wd34349d23034fe..... ",
"transaction":{
"status_request_type":"BIN",
"bin":"424242"
},
}
{
"timestamp":"20170612200234",
"company_id":"133",
"company_pass":"password ",
"request_hash":"ffs934d87d3240dw32..... ",
"transaction":{
"status_request_type":"TRANSACTION_ID_CHILDREN_SUCCESS",
"transaction_id":"138210"
},
}
{
"timestamp":"20170612200244",
"company_id":"133",
"company_pass":"password ",
"request_hash":"vdrv342487dsclelvs..... ",
"transaction":{
"status_request_type":"ORDER_ID_ALL",
"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".

{
"timestamp":"20170612200225",
"company_id":"133",
"result_code":"1 ",
"result_message":"Success",
"response_hash":"",
"bin":{
"issuing_bank":"JPMORGAN CHASE BANK NA",
"card_category":"CREDIT",
"card_level":"STANDARD",
"issuing_country":"United States",
"issuing_country_iso2":"US"
},
}
{
"timestamp":"20170612200235",
"company_id":"133",
"result_code":"1 ",
"result_message":"Success",
"response_hash":"",
"total_transaction":"2",
"transaction": [ {
"mid":"1045",
"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":{
"issuing_bank":"JPMORGAN CHASE BANK NA",
"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":{
"issuing_bank":"JPMORGAN CHASE BANK NA",
"card_category":"CREDIT",
"card_level":"STANDARD",
"issuing_country":"United States",
"issuing_country_iso2":"US"
}
} ]
}
{
"timestamp":"20170612200245",
"company_id":"133",
"result_code":"1 ",
"result_message":"Success",
"response_hash":"",
"total_transaction":"1",
"transaction": [ {
"mid":"1045",
"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":{
"issuing_bank":"JPMORGAN CHASE BANK NA",
"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 "789" 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 "456" 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
IDA unique ID representing the card / customer.
cardnumberThe credit/debit card number used for the transaction.
card_typeThe type of debit/credit card used for the transaction. E.g. Visa
cardexpThe 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_lnameThe customer's last name.
customer_dobThe customer's date of birth in YYYY-MM-DD format.
billing_zipcodeThe 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_idThe unique ID generated by Acquired for the transaction which also serves as the card token.
cardholder_nameThe cardholder's name as printed on the card.
cardnumberThe credit/debit card number used for the transaction.
card_typeThe type of debit/credit card used for the transaction. E.g. Visa
cardexpThe 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