Merchant Initiated Transactions (MIT)

What is a Merchant Initiated Transaction (MIT)?

A Merchant Initiated Transaction (MIT) is when a merchant initiates a transaction using stored card details when the cardholder is not directly interacting with the merchant at the point of authorisation. Please see the below for the Merchant Initiated Transaction (MIT) reasons we support and guidance on the criteria for use.

  Benefits of supporting MIT

  • Payment details need only be entered by the customer once at time of purchase.
  • Process repeat payments for customers without needing to store their card details on your own system for future use. Payment details are stored securely on our servers.
  • A Merchant Initiated Transaction (MIT) is only processed when a request has been submitted by your system. Merchants can choose when Merchant Initiated Transactions (MIT) are processed.

 

Merchant Initiated Transaction (MIT) Types and Reasons

“A” – Re-authorisation

This is used to re-authorise a previously successfully authorised amount that was not settled before the successful authorisation expired. For example, the cardholder places an order on 1st January and the authorisation attempt submitted on 1st January returns an authorised response. The merchant updates the successful authorisation's settlement status to suspended because they are unable to obtain and deliver the goods/services ordered until 1st February, at which point the original successful authorisation has expired. The parent transaction must be successful and must not be an account check.


“C” – Unscheduled payment

This is used to process an unscheduled Merchant Initiated Transaction (MIT). For example, to top up an account to an agreed minimum balance where the account balance goes below the agreed minimum balance to be maintained. The parent transaction or account check must be successful.


“D” – Delayed Charges

This is used to process an unscheduled Merchant Initiated Transaction (MIT) to cover delayed charges not known to the merchant at the point the product or service was ordered by the cardholder, e.g. to pay for additional delivery costs that were not known at the point of the previous authorisation. The parent transaction must be successful and must not be an account check.


“S” – Resubmission

This is used to request to re-authorise a previously declined authorisation attempt. For example, where a merchant supports deferred authorisation, because the cardholder is no longer directly interacting at the point of authorisation, it is not possible to immediately notify the cardholder of the decline status and request an alternative payment method. In this scenario, the merchant can use the Merchant Initiated Transaction (MIT) "Resubmission" value to re-attempt authorisation for the previously declined amount. The merchant should only retry a maximum of three times. The parent transaction must be declined and must not be an account check.


“X” – No-show

This is used to request authorisation for an agreed-to fee when the cardholder does not show up to complete a purchase for a previously-booked product or service. For example, if a cardholder does not show up to a restaurant, hotel, or car hire booking. The parent transaction or account check must be successful.

 

Process overview

 

  1. Cardholder enters their card details and agrees to the storage and/or use of their card details for the purpose of processing Merchant Initiated Transactions (MIT).


  2. Where the customer agrees to the storage of their card details for the purpose of processing Merchant Initiated Transactions (MIT), the merchant may or may not require to take money from the cardholder at this point. For example:

    Scenario 1
    The cardholder pays £10 sign-up fee as an ECOM transaction at the point the card details are provided/captured.
    Scenario 2
    The merchant does not require payment at the point the card details are provided/captured.

  3. When the merchant is ready to charge the first or next Merchant Initiated Transaction (MIT), the merchant submits a Webservices API AUTH request or uses MyST to process the Merchant Initiated Transaction (MIT).

 

Parent request

This section describes the initial request your system will need to process. You can inherit the payment details submitted in this request in subsequent Merchant Initiated Transactions.

 

Configuration of parent request

Expand the relevant section below to learn how to configure the parent request using your preferred interface.

Parent request using Payment Pages

  Payment Pages is our fully-hosted checkout solution. If you are unfamiliar with our Payment Pages solution, click here to learn more and get started.

  To support the THREEDQUERY then ACCOUNTCHECK flow, Payment Pages customers will need to use the Enhanced Post feature. Click here to learn more.

The THREEDQUERY then AUTH flow is performed by processing a standard, 3-D Secure authenticated transaction using Payment Pages, with additional fields included in the POST, as described below.

<html>
<head>
</head>
<body>
<!--YOUR HTML-->
<form method="POST" action="<DOMAIN>/process/payments/choice">
<input type="hidden" name="credentialsonfile" value="1">
<input type="hidden" name="currencyiso3a" value="USD">
<input type="hidden" name="mainamount" value="100.00">
<input type="hidden" name="sitereference" value="test_site12345">
<input type="hidden" name="sitesecurity" value="hee879a9ab97753b3a768925d50842f10e19fea03fef0b820026b6df92d415866">
<input type="hidden" name="sitesecuritytimestamp" value="2019-05-28 14:22:37">
<input type="hidden" name="stprofile" value="default">
<input type="hidden" name="version" value="2">
<input type="submit" value="Pay">
</form>
</body>
</html>

Replace <DOMAIN> with a supported domain. Click here for a full list.

 

Field specification

  Field Format Description
X1-EN.png mainamount Numeric (14)

The amount associated with this request in main units, with decimal places being separated by commas/decimal point. e.g. £10.99 would be submitted as “10.99” and ¥246 would be submitted as “246”.

This amount will be immediately reserved on the customer’s bank account.

This value will be inherited in all child requests that inherit from this parent request, unless the field is manually overridden.

X1-EN.png credentialsonfile Numeric (1) Visa and Mastercard have mandated that you must obtain cardholder consent before storing card details for future use. Following this, you must appropriately identify credentials that are to be stored for later, by assigning a Credentials on File (CoF) flag to signify this. For this reason, you must always submit credentialsonfile with value “1” in the parent request.
X1-EN.png currencyiso3a Alpha (3) The transaction currency. This must remain the same in all future child requests processed that inherit from this parent request.
X1-EN.png sitereference Alphanumeric
& underscore (50)
The site reference relates to your individual account which you received on setup. If you do not know your site reference, please contact our Support Team.
X1-EN.png sitesecurity

Site security hash

Used to submit the request site security hash in the POST.
X1-EN.png sitesecuritytimestamp

Date YYYY-MM-DD hh:mm:ss 

As accurately as possible, the timestamp that reflects when the customer’s payment session was initiated. The customer will have 3 hours from the specified time to complete the payment.

Additional considerations:

  • The timestamp value must be in UTC.
  • The timestamp value must NOT be in the future.
X1-EN.png stprofile

Alphanumeric (20)

  • Lowercase letters only.
  • Punctuation and spaces not permitted.
Used to specify the styling used to render the Payment Pages. When using the default appearance, this is set to “default”.
Click here for further information.

 

Response

You will need to ensure your system stores the transactionreference field returned in the browser redirect at the end of the checkout session (if configured), and/or the URL notification (if configured), as this must be referenced in the child request that is submitted later.

Parent request using JavaScript Library

  Our JavaScript Library provides resources to help you quickly build your own streamlined checkout solution on the web. If you are unfamiliar with our JavaScript Library solution, click here to learn more and get started.

  • Both the [“THREEDQUERY”,”AUTH”] and [“THREEDQUERY”,”ACCOUNTCHECK”] parent requests follow a similar specification to that of a standard payment processed using our JavaScript Library, but are subject to different requirements when employed as part of a Merchant Initiated Transactions solution.
  • These changes are made within the payload of the JWT.
  • Refer to the example and field specification below for further information.
{
"payload":{
"accounttypedescription":"ECOM",
"baseamount":"1050",
"credentialsonfile":"1",
"currencyiso3a":"GBP",
"requesttypedescriptions":["THREEDQUERY","AUTH"]
"sitereference":"test_site12345"
},
"iat":1559033849,
"iss":"jwt.user"
}

 

Field specification

  Field Format Description
X1-EN.png accounttypedescription Alpha (20)

Submit "ECOM" to indicate an e-commerce transaction.

We recommend contacting our Support Team for advice on which account type values are supported on your site reference.

X1-EN.png baseamount Numeric (13)

The amount associated with this request in base units, with no commas or decimal points. e.g. £10.99 would be submitted as “1099” but ¥246 would be submitted as “246”.

  • For an initial [“THREEDQUERY”,”AUTH”] request: This amount will be immediately reserved on the customer’s bank account.
  • For an initial [“THREEDQUERY”,”ACCOUNTCHECK”] request: No funds are reserved on the customer’s bank account.

This value will be inherited in all child requests that inherit from this parent request, unless the field is manually overridden.

X1-EN.png credentialsonfile Numeric (1) Visa and Mastercard have mandated that you must obtain cardholder consent before storing card details for future use. Following this, you must appropriately identify credentials that are to be stored for later, by assigning a Credentials on File (CoF) flag to signify this. For this reason, you must always submit credentialsonfile with value “1” in the parent request.

The value submitted here is returned in the response JWT.

X1-EN.png currencyiso3a Alpha (3) The transaction currency. This must remain the same in all future child requests processed that inherit from this parent request.
X1-EN.png requesttypedescriptions List The request types to be processed.
For the parent, this should be either [“THREEDQUERY”,”AUTH”] or [“THREEDQUERY”,”ACCOUNTCHECK”]
X1-EN.png sitereference Alphanumeric
& underscore (50)
The site reference relates to your individual account which you received on setup. If you do not know your site reference, please contact our Support Team.

 

Response

The response JWT returned follows the same specification as when processing a standard payment. Of particular importance, your system will need to store the transactionreference returned, as this must be referenced in the child request that is submitted later. Click here to learn about decoding the JWT response.

Parent request using Mobile SDK

  Our Mobile SDK provides resources to help you quickly build a streamlined checkout solution into your mobile app. If you are unfamiliar with our Mobile SDK solution, click here to learn more and get started.

  • Both the [“THREEDQUERY”,”AUTH”] and [“THREEDQUERY”,”ACCOUNTCHECK”] parent requests follow a similar specification to that of a standard payment processed using our Mobile SDK, but are subject to different requirements when employed as part of a Merchant Initiated Transactions solution.
  • These changes are made within the payload of the JWT.
  • Refer to the example and field specification below for further information.
{
"payload":{
"accounttypedescription":"ECOM",
"baseamount":"1050",
"credentialsonfile":"1",
"currencyiso3a":"GBP",
"requesttypedescriptions":["THREEDQUERY","AUTH"]
"sitereference":"test_site12345",
"termurl":"https://payments.securetrading.net/process/payments/mobilesdklistener"
},
"iat":1559033849,
"iss":"jwt.user"
}

 

Field specification

  Field Format Description
X1-EN.png accounttypedescription Alpha (20)

Submit "ECOM" to indicate an e-commerce transaction.

We recommend contacting our Support Team for advice on which account type values are supported on your site reference.

X1-EN.png baseamount Numeric (13)

The amount associated with this request in base units, with no commas or decimal points. e.g. £10.99 would be submitted as “1099” but ¥246 would be submitted as “246”.

  • For an initial [“THREEDQUERY”,”AUTH”] request: This amount will be immediately reserved on the customer’s bank account.
  • For an initial [“THREEDQUERY”,”ACCOUNTCHECK”] request: No funds are reserved on the customer’s bank account.

This value will be inherited in all child requests that inherit from this parent request, unless the field is manually overridden.

X1-EN.png credentialsonfile Numeric (1) Visa and Mastercard have mandated that you must obtain cardholder consent before storing card details for future use. Following this, you must appropriately identify credentials that are to be stored for later, by assigning a Credentials on File (CoF) flag to signify this. For this reason, you must always submit redentialsonfile with value “1” in the parent request.

The value submitted here is returned in the response JWT.

X1-EN.png currencyiso3a Alpha (3) The transaction currency. This must remain the same in all future child requests processed that inherit from this parent request.
X1-EN.png requesttypedescriptions List The request types to be processed.
For the parent, this should be either [“THREEDQUERY”,”AUTH”] or [“THREEDQUERY”,”ACCOUNTCHECK”]
X1-EN.png sitereference Alphanumeric
& underscore (50)
The site reference relates to your individual account which you received on setup. If you do not know your site reference, please contact our Support Team.
X1-EN.png termurl URL (1024)

This URL is used to instruct the card issuer where to send the customer’s browser after they have been authenticated on the card issuer’s ACS. You must submit the following URL in this field when performing 3-D Secure:

https://payments.securetrading.net/process/payments/mobilesdklistener

 

Response

The response JWT returned follows the same specification as when processing a standard payment. Of particular importance, your system will need to store the transactionreference returned, as this must be referenced in the child request that is submitted later. Click here to learn about decoding the JWT response.

Parent request using Webservices API (ECOM)

  Our Webservices API is a powerful server-to-server payment processing solution that supports multiple message types. If you are unfamiliar with our Webservices API, click here to learn more and get started.

  • The example below is an AUTH request that can be used to process the first payment in the Merchant Initiated Transactions flow.
  • The accounttypedescription is "ECOM" to indicate the transaction was performed using your website.
  • If you need to start a Merchant Initiated Transactions agreement without processing a payment, you can change the requesttypedescriptions value to "ACCOUNTCHECK".
Python PHP cURL Raw JSON Raw XML

#!/usr/bin/python
import securetrading

stconfig = securetrading.Config()
stconfig.username = "webservices@example.com"
stconfig.password = "Password1^"
st = securetrading.Api(stconfig)

auth = {
"sitereference": "test_site12345",
"requesttypedescriptions": ["AUTH"],
"accounttypedescription": "ECOM",
"currencyiso3a": "GBP",
"baseamount": "1050",
"orderreference": "My_Order_123",
"pan": "4111111111111111",
"expirydate": "12/2020",
"securitycode": "123",
"cavv":"Q0FWVkNBVlZDQVZWQ0FWVkNBVlY=",
"eci":"05",
"enrolled":"Y",
"status":"Y",
"threedversion":"2.1.0", "threeddirectorytransactionreference":"f00e1111-0011-00a6-ab00-a00000a00000",
"credentialsonfile": "1"
}

strequest = securetrading.Request()
strequest.update(auth)
stresponse = st.process(strequest) #stresponse contains the transaction response
  Field Format Description
X1-EN.png accounttypedescription
XPath: /operation/accounttypedescription
Alpha (20)

Submit "ECOM" to indicate an e-commerce transaction.

X1-EN.png baseamount
XPath: /billing/amount
Numeric (13)

The amount associated with this request in base units, with no commas or decimal points. e.g. £10.99 would be submitted as “1099” but ¥246 would be submitted as “246”.

This value will be inherited in all child requests that inherit from this parent request, unless the field is manually overridden.

  Where performing an ACCOUNTCHECK, you must include the maximum amount to be processed in any subsequent child transaction.

X1-EN.png credentialsonfile
XPath: /operation/credentialsonfile
Numeric (1) Visa and Mastercard have mandated that you must obtain cardholder consent before storing card details for future use. Following this, you must appropriately identify credentials that are to be stored for later, by assigning a Credentials on File (CoF) flag to signify this. For this reason, you must always submit credentialsonfile with value “1” in the parent request.

The value submitted here is returned in the response JWT.

X1-EN.png currencyiso3a
XPath: /billing/amount/@currencycode
Alpha (3) The transaction currency. This must remain the same in all future child requests processed that inherit from this parent request.
X1-EN.png enrolled
XPath: /threedsecure/enrolled
Char (1) Submit ‘Y’ to indicate that card is enrolled. See below for information on handling not-enrolled cards.
X1-EN.png expirydate
XPath: /billing/payment/expirydate
Date MM/YYYY The expiry date printed on the card.
X1-EN.png pan
XPath: /billing/payment/pan
Numeric (12-19) This is the long number printed on the front of the customer’s card.
X1-EN.png requesttypedescriptions
XPath: /@type
List The request types to be processed.
For the parent, this should be either ["AUTH"] or ["ACCOUNTCHECK"]
X1-EN.png sitereference
XPath: /operation/sitereference
Alphanumeric
& underscore (50)
The site reference relates to your individual account which you received on setup. If you do not know your site reference, please contact our Support Team.
X1-EN.png status
XPath: /threedsecure/status
Char (1) Indicates whether or not the customer was authenticated on the card issuer’s ACS.

Successful authentication with status "Y" is required.

X2-EN.png billingfirstname
XPath: /billing/name/first
Alphanumeric including
symbols (127)

The customer’s billing first name.

Required for gaming merchants.

X2-EN.png billinglastname
XPath: /billing/name/last
Alphanumeric including
symbols (127)

The customer’s billing last name.

Required for gaming merchants.

X2-EN.png cavv
XPath: /threedsecure/cavv
Alphanumeric (56)

The unique Cardholder Authentication Verification Value (CAVV) associated with the transaction.

Always submit this value when it is available.

X2-EN.png eci
XPath: /threedsecure/eci
Alphanumeric (2)

The ECI (E-Commerce Indicator) security level associated with the transaction.

Always submit this value when it is available.

X2-EN.png threedversion
XPath: /threedsecure/version
Numeric (6)

Version of 3-D Secure used to authenticate the payment. (e.g. “2.1.0”)

Always submit this value when it is available.

X2-EN.png threeddirectorytransactionreference
XPath: /threedsecure/directorytransactionreference
Alphanumeric (48)

Unique DSTransactionId returned by your MPI provider.

Always submit this value when it is available.

X3-EN.png securitycode
XPath: /billing/payment/securitycode
Numeric (3-4)

This is the 3-digit security code printed on the back of the card.

(For AMEX cards, this is a 4-digit code found on the front of the card)

This field is not strictly required by Trust Payments, but it is highly recommended for the processing of security code checks.

Additionally, some banks may decline the payment if the security code is not present.

 

Response

The response returned follows the same specification as a standard AUTH response.

 

Parent request using Webservices API (MOTO)

  Our Webservices API is a powerful server-to-server payment processing solution that supports multiple message types. If you are unfamiliar with our Webservices API, click here to learn more and get started.

  • The example below is an AUTH request that can be used to process the first payment in the Merchant Initiated Transactions flow.
  • The accounttypedescription is "MOTO" to indicate the order was placed over the phone.
  • If you need to start a Merchant Initiated Transactions agreement without processing a payment, you can change the requesttypedescriptions value to "ACCOUNTCHECK".
Python PHP cURL Raw JSON Raw XML

#!/usr/bin/python
import securetrading

stconfig = securetrading.Config()
stconfig.username = "webservices@example.com"
stconfig.password = "Password1^"
st = securetrading.Api(stconfig)

auth = {
"sitereference": "test_site12345",
"requesttypedescriptions": ["AUTH"],
"accounttypedescription": "MOTO",
"currencyiso3a": "GBP",
"baseamount": "1050",
"orderreference": "My_Order_123",
"billingfirstname": "Joe",
"billinglastname": "Bloggs",
"pan": "4111111111111111",
"expirydate": "12/2020",
"securitycode": "123",
"credentialsonfile": "1"
}

strequest = securetrading.Request()
strequest.update(auth)
stresponse = st.process(strequest) #stresponse contains the transaction response
  Field Format Description
X1-EN.png accounttypedescription
XPath: /operation/accounttypedescription
Alpha (20)

Submit "MOTO" to indicate a Mail Order Telephone Order transaction.

(Note that 3-D Secure authentication is not supported for MOTO transactions)

X1-EN.png baseamount
XPath: /billing/amount
Numeric (13)

The amount associated with this request in base units, with no commas or decimal points. e.g. £10.99 would be submitted as “1099” but ¥246 would be submitted as “246”.

This value will be inherited in all child requests that inherit from this parent request, unless the field is manually overridden.

  Where performing an ACCOUNTCHECK, you must include the maximum amount to be processed in any subsequent child transaction.

X1-EN.png credentialsonfile
XPath: /operation/credentialsonfile
Numeric (1) Visa and Mastercard have mandated that you must obtain cardholder consent before storing card details for future use. Following this, you must appropriately identify credentials that are to be stored for later, by assigning a Credentials on File (CoF) flag to signify this. For this reason, you must always submit credentialsonfile with value “1” in the parent request.

The value submitted here is returned in the response JWT.

X1-EN.png currencyiso3a
XPath: /billing/amount/@currencycode
Alpha (3) The transaction currency. This must remain the same in all future child requests processed that inherit from this parent request.
X1-EN.png expirydate
XPath: /billing/payment/expirydate
Date MM/YYYY The expiry date printed on the card.
X1-EN.png pan
XPath: /billing/payment/pan
Numeric (12-19) This is the long number printed on the front of the customer’s card.
X1-EN.png requesttypedescriptions
XPath: /@type
List The request types to be processed.
For the parent, this should be either ["AUTH"] or ["ACCOUNTCHECK"]
X1-EN.png sitereference
XPath: /operation/sitereference
Alphanumeric
& underscore (50)
The site reference relates to your individual account which you received on setup. If you do not know your site reference, please contact our Support Team.
X2-EN.png billingfirstname
XPath: /billing/name/first
Alphanumeric including
symbols (127)

The customer’s billing first name.

Required for gaming merchants.

X2-EN.png billinglastname
XPath: /billing/name/last
Alphanumeric including
symbols (127)

The customer’s billing last name.

Required for gaming merchants.

X3-EN.png securitycode
XPath: /billing/payment/securitycode
Numeric (3-4)

This is the 3-digit security code printed on the back of the card.

(For AMEX cards, this is a 4-digit code found on the front of the card)

This field is not strictly required by Trust Payments, but it is highly recommended for the processing of security code checks.

Additionally, some banks may decline the payment if the security code is not present.

 

Response

The response returned follows the same specification as a standard AUTH response.

 

  Your progress

After following the instructions above, you should now be ready to manually process repeat payments using our Webservices API. You can take the transactionreference returned in the response and include this in subsequent child requests.

 


 

Child request

  This section describes the subsequent Merchant Initiated Transactions. This section assumes the parent request described earlier has already been processed.

  Before processing a child request, you must ensure that the parent request has completed successfully. Investigate any issues raised and if assistance is required, contact our Support Team.

  When a parenttransactionreference from a successful parent "AUTH" or "ACCOUNTCHECK" is included in a child request, Trust Payments will provide the required scheme reference data to Visa and Mastercard.

Please contact our Support Team if you need to include scheme reference data from another processor or process child transactions including a PAN and Expiry. Click here to learn more.

 

Child request overview

  1. Your system requests that a new payment is processed, by manually submitting an AUTH request using our Webservices API, which includes the transactionreference of the parent AUTH or ACCOUNTCHECK in the parenttransactionreference field.

  For those using our JavaScript Library or Mobile SDK to process the parent request, the subsequent response JWT returned will also contain the transactionreference of the THREEDQUERY. You must not submit this in the child request. Instead, you must only submit the transactionreference value associated with the parent AUTH or ACCOUNTCHECK.

  1. We contact the acquiring bank to seek authorisation for the payment, using the billing and delivery details inherited from the parent AUTH/ACCOUNTCHECK. (Your system does not need to re-submit these details)
  2. Your system receives an AUTH response, including the results of the request.

 

Request

The request type submitted for the child request must be “AUTH” (submitted in the requesttypedescriptions field). The AUTH child request follows a similar specification to a standard AUTH request, but is subject to different requirements when employed as part of a Merchant Initiated Transactions solution. Refer to the example and field specification below for further information.

Python PHP cURL Raw JSON Raw XML
#!/usr/bin/python
import securetrading

stconfig = securetrading.Config()
stconfig.username = "webservices@example.com"
stconfig.password = "Password1^"
st = securetrading.Api(stconfig)

auth = {
"sitereference": "test_site12345",
"requesttypedescriptions": ["AUTH"],
"accounttypedescription": "ECOM",
"initiationreason": "C",
"parenttransactionreference": "12-3-4567",
"baseamount": "1050",
"credentialsonfile": "2"
}

strequest = securetrading.Request()
strequest.update(auth)
stresponse = st.process(strequest) #stresponse contains the transaction response

Replace <DOMAIN> with a supported domain. Click here for a full list.

 

  The example above assumes that the previous request was the first to be processed, therefore the subscriptionnumber is assigned value “2”. Subsequent child requests are processed with the same structure, incrementing this number each time (i.e. next payment in sequence would be “3”, then “4” and so on).

  Field Format Description
X1-EN.png accounttypedescription
XPath: /operation/accounttypedescription
Alpha (20) Submit the same accounttypedescription value in the child request as in the linked parent.
X3-EN.png baseamount
XPath: /billing/amount
Numeric (13)

The amount associated with the child payment in base units, with no commas or decimal points. e.g. £10.99 would be submitted as “1099” but ¥246 would be submitted as “246”.

If you don’t submit this field, the amount processed will be inherited from the preceding parent request.

X1-EN.png credentialsonfile
XPath: /operation/credentialsonfile
Numeric (1)

This is required for Visa and Mastercard transactions where the merchant is utilising Credentials on File (CoF).

Submit “2” in this field to indicate the payment is using previously-stored credentials.

X3-EN.png currencyiso3a
XPath: /billing/amount/@currencycode
Alpha (3) If submitted, this must be the same currency used in the parent request.

If not submitted, this value is inherited from the parent request.

X1-EN.png initiationreason
XPath: /operation/initiationreason
Char (1) It is mandated you provide a reason for processing the tokenized payment. Submit one of the following values that best describes the reason for payment:
  • “A” – Re-authorisation
  • “C” – Unscheduled payment
  • “D” – Delayed Charges
  • “S” – Resubmission
  • “X” – No-show (for a hotel booking)
X1-EN.png parenttransactionreference
XPath: /operation/parenttransactionreference
Alphanumeric
& hyphens (25)
You must submit the transactionreference value of the AUTH or ACCOUNTCHECK returned in the response JWT of the initial parent request.

You must not submit the transactionreference value associated with the THREEDQUERY.

X1-EN.png requesttypedescriptions
XPath: /@type
Alpha (20) You must submit “AUTH”, as shown in the request example.
X1-EN.png sitereference
XPath: /operation/sitereference
Alphanumeric
& underscore (50)
The site reference relates to your individual account which you received on setup. If you do not know your site reference, please contact our Support Team.

 

Response

The response returned follows the same specification as a standard AUTH response, with the exception of the additional field acquireradvicecode that can be returned (see the field specification below for further information).

 

Field specification

  Field Format Description
X4-EN.png accounttypedescription
XPath: /operation/accounttypedescription
Alpha (20) Account type “RECUR” will be returned.
X2-EN.png acquireradvicecode
XPath: /acquireradvicecode
Numeric (1)

A numeric value returned from the acquiring bank, which is used to indicate whether further payments can be processed. A full mapping of these values can be found in the “Additional notes” section at the bottom of this page.

Only returned if supported by your acquiring bank.

X4-EN.png baseamount
XPath: /billing/amount
Numeric (13)

The amount associated with the child payment in base units, with no commas or decimal points. e.g. £10.99 would be submitted as “1099” but ¥246 would be submitted as “246”.

We recommend checking this amount matches the value you are expecting. The amount returned here reflects the amount the customer will be debited on the child payment.

X4-EN.png credentialsonfile
XPath: /operation/credentialsonfile
Numeric (1) If the credentialsonfile field has been submitted in the request and it is supported by the acquirer processing the transaction, it is returned in the response.
X4-EN.png currencyiso3a
XPath: /billing/amount/@currencycode
Alpha (3)

The currency of the transaction.

Click here for a full list of available currencies.

X4-EN.png parenttransactionreference
XPath: /operation/parenttransactionreference
Alphanumeric
& hyphens (25)
The transaction reference of the parent transaction.
X4-EN.png requesttypedescription
XPath: /@type
Alpha (20) Request type “AUTH” will be returned.

  Summary

Following the instructions above, your system should now be able to manually process repeat payments using our Webservices API, without needing to re-submit any of the customer’s billing or payment credentials. As always, we strongly recommend thoroughly testing your solution to ensure Merchant Initiated Transactions are being processed as expected, before performing live payments on your production system. Please read on for additional information you may find useful when developing a Merchant Initiated Transactions solution.

 

Additional notes

 

Below are some additional notes to consider when processing Merchant Initiated Transactions.

 

About the acquirer advice code

The acquirer advice code is a numeric value returned if supported by your acquiring bank, indicating if and when further payments can be processed.

  Click here to learn more

Related articles


Recurring payments

Process repeat transactions from previously stored card details.

  Learn more

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request