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

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

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]

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.

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.

The endpoints for the Acquired Hosted Payment Page are:

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.

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://.

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";

?>

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>

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

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.

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.

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

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); 
?>

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.

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}}">

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.

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:

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:

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

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.

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.

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:

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:

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

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:

The rebill operation requires two additional parameters than regular AUTH_ONLY and AUTH_CAPTURE transaction types:

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.

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:

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.

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:

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.

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:

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

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.

Please contact [email protected] to activate 3-D Secure on your account.

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

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.

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:

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:

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:

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.

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.

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.

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:

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

The following is an example of an AUTH_ONLY SETTLEMENT transaction response where the cardholder has successfully authenticated themselves:

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:

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

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

The following table describes these additional request parameters:

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:

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.

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);

    }
    

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:

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:

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

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.

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.

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:

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:

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.

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.

MasterCard