One-Click Checkout

Overview

Here’s a different scenario - the cardholder is present on your website, but you still need us to decrypt a previously stored card number for the payment method. Just set the subscription_type parameter to REUSE.

API

Endpoints

Time to play - access your API using these endpoints:

Here’s an example 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"
    },
    }
  

REUSE Request Parameters

Parameter Format Length Description
subscription_type string 4 - 14 Set to REUSE to use an exisitng token.
Acceptable Characters: a-Z A-Z _
original_transaction_id int 1 - 11 transaction_id value we generated and returned in the original INIT request.
Acceptable Characters: 0-9
amount int 1 - 11 Transaction amount.
Acceptable Characters: 0-9 in the format DDDDDD.CC
currency_code_iso3 string 3 Transaction currency, an ISO 4217 3-digit code.
Acceptable Characters: a-z A-Z
billing object
cardcvv int 3 - 4 The 3 - 4 digit card verification number.
Acceptable Characters: 0-9
tds object
action string 7 - 10 Set value to ENQUIRE

But wait, you may say. REUSE is the same as REBILL, right? Not quite. Using REUSE instead of REBILL lets the card issuer know that the cardholder was present on your website when the payment initiates and you process an adhoc payment. It’s a security thing.

Here’s some information on implementing 3-D Secure as part of a REUSE request. If you go that route, the resulting ENQUIRE response will follow the typical 3D Secure format and flow.

Otherwise, the REUSE response is the same as a standard authorisation transaction type. You can look that up here.

Key info - When processing a reuse request, the transaction will be required to be authenticated using 3-D Secure 2.1 from 14th September 2019 and onwards due to SCA requirements.

Hosted Payment Page

Endpoints

Time to play - access your API using these endpoints:

Here’s an example of a REUSE authorisation request including both CVV and 3-D Secure:

<!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="113">
    <input type=hidden name="company_mid_id" value="1045">
    <input type=hidden name="currency_code_iso3" value="GBP">
    <input type=hidden name="transaction_type" value="AUTH_CAPTURE"> 
    <input type=hidden name="merchant_order_id" value="20170619111"> 
    <input type=hidden name="amount" value="14.99">
    <input type=hidden name="subscription_type" value="REUSE">
    <input type=hidden name="original_transaction_id" value="123456">
    <input type=hidden name="is_tds" value="2">
    <input type=hidden name="merchant_contact_url" value="https://yourdomain.com/method_notification_url">
    <input type=hidden name="tds_source" value="1">
    <input type=hidden name="tds_type" value="2">
    <input type=hidden name="tds_preference" value="2">
    <input type=hidden name="hash" value="2934149504e39101f5cfad6ec3e971978890a057373ac3237e0dd150dd491d3d3">                        <input type=submit value="Submit"> 
    </form>
</body>
</html>

REUSE Request Parameters

Parameter Format Length Description
company_id int 1-4 Company ID we issue to merchants.
Acceptable Characters: 0-9
company_mid_id int 1-11 Merchant ID we issue to merchants.
Acceptable Characters: 0-9
currency_code_iso3 string 3 Transaction currency, an ISO 4217 3-digit code.
Acceptable Characters: a-Z A-Z
transaction_type string 1 - 20 For more information on the possible transaction_type values, please see here
Acceptable Characters: a-z A-Z _
merchant_order_id string 1-50 Unique ID you’ll use to identify each transaction.
Acceptable Characters: a-z A-Z 0-9 _ -
amount int 1 - 11 Transaction amount.
Acceptable Characters: 0-9 in the format DDDDDD.CC
subscription_type string 4 - 14 Value should be set to REUSE
Acceptable Characters: a-Z A-Z _
original_transaction_id int 1 - 11 transaction_id value we generated and returned in the original INIT request.
Acceptable Characters: 0-9
is_tds int 1 Flag to initiate 3-D Secure / SCA authentication. Should be set to 2 to enable both versions of 3-D Secure.
Acceptable Characters: 0/1
merchant_contact_url string 1-50 A link to the Contact Us page on your website for example: https://yourdomain/contact.
Acceptable Characters: 0-9 a-z A-z - . _ ~ : / ? # [ ] @ ! $ & ' ( ) * + , ; = ` .
tds_source int 1 The channel being used to initiate the transaction:

1 = Browser
2 = Mobile SDK

Acceptable Characters: 0-9
tds_type int 1 The type of transaction you are processing:

1 = Cardholder Verification (Zero Value Auth)
2 = Ad hoc payment (Customer Present)
3 = Recurring (Setting up a monthly payment for the same amount)

Acceptable Characters: 0-9
tds_preferences int 1 If you'd like the customer to be challenged:

0 = No Preference
1 = Don't Challenge
2 = Request Challenge

The issuer may decide to ignore your preference.

Acceptable Characters: 0-9

But wait, you may say. REUSE is the same as REBILL, right? Not quite. Using REUSE instead of REBILL lets the card issuer know that the cardholder was present on your website when the payment initiates and you process an adhoc payment. It’s a security thing.

Here’s some information on implementing 3-D Secure as part of a REUSE request. If you go that route, the resulting ENQUIRE response will follow the typical 3D Secure format and flow.

Otherwise, the REUSE response is the same as a standard authorisation transaction type. You can look that up here.

Key info - When processing a reuse request, the transaction will be required to be authenticated using 3-D Secure 2.1 from 14th September 2019 and onwards due to SCA requirements.