One-Click Checkout

Overview

Here’s a different scenario - your customer is present on your website and would like to make a payment with a previously used card. You can then use the tokenised details to pre-populate your payment page with their details - leaving only CVV value blank.

The customer then just has to enter in their CVV value and the payment has been completed.

Within the request, 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 initiated and you are processing 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.

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

If you decide to not use 3-D Secure, the response is the same as a standard authorisation.

Key Info When processing a REUSE request, the transaction will be required to be authenticated using 3-D Secure 2.1 from September 2021.

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 Value should be set to AUTH_CAPTURE.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 authentication. Value should be set to 2.
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