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