Loading...
A merchant-initiated transaction (MIT) refers to a card payment made by a merchant without the customer being actively involved, as part of an agreement made during an initial customer-initiated transaction (CIT).
For an MIT to be considered out of scope for Strong Customer Authentication (SCA):
When flagged correctly, MITs are deemed as out of scope of the SCA requirements under Revised PSD2 within Europe and the UK. This allows MITs to be processed without further cardholder authentication required.
The following table describes the different types of MITs.
| MIT Type | Description |
| Recurring | Transaction with a fixed amount but no fixed duration in which the merchant continues to process payments with the cardholder’s credentials until the cardholder cancels (for example, a subscription or a gym membership). |
| Installments | Transaction with a fixed amount and duration in which the merchant can’t process the cardholder’s credentials once this fixed period ends. Installments are paid at an agreed amount on the same day of each month (for example, paying for a kitchen appliance over 12 months interest free). |
| Oneoff | Unscheduled transaction with no fixed duration but with an agreed amount (for example, a travel card “top up” if the credit falls below a certain limit). |
To learn how to set up an MIT, use the applicable guide below.
In this guide, we use our Card Storage solution to set up an MIT that is out of scope for SCA. To adhere to scheme rules, we first perform a 3D Secure 2 payment authentication, even though we’re not charging the card before we store it. Next, we follow the standard practice for card storage, which includes performing a validation (open-to-buy, OTB), creating the payer, and then storing the card against it.
But first, we cover the scheme rules for setting up MITs and how they relate to SCA, 3D Secure 2, and exemptions. If you prefer to get right to implementing an MIT, skip ahead to Step 1.
For an MIT to qualify as out of scope, two conditions must be met: 1) the initial transaction undergoes 3D Secure payment authentication with the Challenge Mandated flag to ensure a cardholder challenge and 2) all subsequent transactions include the correct credential on file (COF) data.
When setting up an MIT, scheme rules require that merchants first perform a 3D Secure 2 payment authentication before storing the card details. Therefore, during the initial CIT in which the customer gives consent to store their credentials for future use, the merchant must always perform a payment authentication (as opposed to a non-payment authentication). This is true regardless of whether the merchant is actually charging the card at the time or just validating it (OTB).
A COF refers to card data for a particular customer (that is, their primary account number and expiration date), which has been stored with their consent. A COF indicates to Issuers and Acquirers that the merchant is storing the customer's card details, and the information is used by them when subsequent payments are made by the merchant. In order for an MIT to qualify as out of scope from SCA, the merchant must submit the correct COF data at each stage.
For merchants using our Card Storage solution, COF data for MITs is populated with default values automatically. For more information on how we handle COF data, see Credential On File.
The following table describes the key COF data points.
| Field | Value |
| Message Category | Payment authentication (even if the customer initiated transaction is not a charge; for example, a card validation open-to-buy) |
| Challenge Request Indicator | Challenge mandated |
curl https://api.sandbox.globalpay-ecommerce.com/3ds2/authentications
-H "Content-type: application/json"
-H "Authorization: securehash abafc599cfa60c94b8f41d0668dac5ed6b0a21f7"
-X POST
-d '{
"request_timestamp": "2020-08-31T16:42:33",
"authentication_source": "BROWSER",
"authentication_request_type": "ADD_CARD",
"message_category": "PAYMENT_AUTHENTICATION",
"message_version": "2.1.0",
"challenge_request_indicator": "CHALLENGE_MANDATED",
"server_trans_id": "65a9aa48-8400-4eab-b9ee-67df7facb004",
"merchant_id": "MerchantId",
"account_id": "internet",
"card_detail": {
"number": "4263970000005262",
"scheme": "VISA",
"expiry_month": "10",
"expiry_year": "25",
"full_name": "James Mason"
},
"order": {
"date_time_created": "2020-08-31T16:42:552327Z",
"id": "3400dd37-101d-4940-be15-3c963b6109b3",
"address_match_indicator": "false",
"shipping_address": {
"line1": "Apartment 852",
"line2": "Complex 741",
"line3": "House 963",
"city": "Chicago",
"postal_code": "50001",
"state": "IL",
"country": "840"
}
},
"payer": {
"email": "james.mason@example.com",
"billing_address": {
"line1": "Flat 456",
"line2": "House 456",
"line3": "Unit 4",
"city": "Halifax",
"postal_code": "W5 9HR",
"country": "826"
},
"mobile_phone": {
"country_code": "44",
"subscriber_number": "7123456789"
}
},
"challenge_notification_url": "https://www.example.com/challengeNotificationUrl",
"method_url_completion": "YES",
"browser_data": {
"accept_header": "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8",
"color_depth": "TWENTY_FOUR_BITS",
"ip": "123.123.123.123",
"java_enabled": "true",
"javascript_enabled": "true",
"language": "en-US",
"screen_height": "1080",
"screen_width": "1920",
"challenge_window_size": "FULL_SCREEN",
"timezone": "0",
"user_agent": "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36"
},
"merchant_contact_url": "https://www.example.com/about"The Issuer’s response includes the necessary details required to authenticate the customer, as in a standard 3D Secure 2 challenge flow. For more information on authentication, see the API Reference for 3D Secure 2.
An OTB transaction allows you to check that a card is still valid and active without actually processing a payment against it. While the outcome of the payment authentication will tell us this, the OTB will also allow us to perform the Security Code (CVN) and Address Verification Service (AVS) checks before storing the card. A scheme reference data (SRD) value will also be returned, which is important for subsequent transactions using these stored card details.
<?xml version="1.0" encoding="UTF-8"?>
<request type="otb" timestamp="20200831164233">
<merchantid>MerchantId</merchantid>
<account>internet</account>
<orderid>XmUfe9XqCfYBuqVJZBjv5T</orderid>
<card>
<number>4263970000005262</number>
<expdate>1025</expdate>
<chname>James Mason</chname>
<type>VISA</type>
<cvn>
<number>123</number>
<presind>1</presind>
</cvn>
<mpi>
<eci>5</eci>
<ds_trans_id>65a9aa48-8400-4eab-b9ee-67df7facb004</ds_trans_id>
<authentication_value>MTIzNDU2Nyg5MDA5ODc2NTQzMjE=</authentication_value>
<message_version>2.1.0</message_version>
</mpi>
</card>
<sha1hash>11e5d2ce54eec98892155715497e5c4c4866d998</sha1hash>
</request>To store a card, first set up a customer reference (payer). You can also choose to store address and contact details for the customer. In this example, we’re using a random string generator for the customer references.
<?xml version="1.0" encoding="UTF-8"?>
<request type="payer-new" timestamp="20200831164233">
<merchantid>MerchantId</merchantid>
<account>internet</account>
<orderid>OL0f0VYFQTyNG5IulhsMrg</orderid>
<payer ref="0f357b45-9aa4-4453-a685-c69232e9024f" type="Retail">
<title>Mr.</title>
<firstname>James</firstname>
<surname>Mason</surname>
<company>Global Payments</company>
<address>
<line1>Flat 123</line1>
<line2>House 456</line2>
<line3>The Cul-De-Sac</line3>
<city>Halifax</city>
<county>West Yorkshire</county>
<postcode>W6 9HR</postcode>
<country code="GB">United Kingdom</country>
</address>
<phonenumbers>
<home>+35312345678</home>
<work>+3531987654321</work>
<fax>+124546871258</fax>
<mobile>+25544778544</mobile>
</phonenumbers>
<email>text@example.com</email>
<dateofbirth>19851222</dateofbirth>
<state>Yorkshire and the Humber</state>
<passphrase>montgomery</passphrase>
<vatnumber>GB 123456789</vatnumber>
<varref>Car Part HV</varref>
<custnum>E8953893489</custnum>
</payer>
<sha1hash>8d7e42bba0d9f6ca81f6106bfd74d2911fad888b</sha1hash>
</request>Once the customer entity is created, you can now add cards to it. This request must contain the card data to be stored, a unique reference for it, and the customer reference it is to be added to.
Storing the COF sequence against the card indicates that the next transaction will be identified as subsequent rather than first, which is important if Global Payments is generating default values for your COF transactions. To link the initial authentication to subsequent recurring transactions, the SRD returned in the initial CIT response must be included.
Now that you've stored the card, you can raise payments against it at a future date or enable a simple one-click checkout experience for the customer. For information on working with stored cards, see the API Reference for Card Storage.
<?xml version="1.0" encoding="UTF-8"?>
<request type="card-new" timestamp="20200831164233">
<merchantid>MerchantId</merchantid>
<account>internet</account>
<orderid>F-2knQ0iShKK6ezfaSLh2Q</orderid>
<card>
<ref>10c6a2c7-be7b-a13f-12638937a012</ref>
<payerref>0f357b45-9aa4-4453-a685-c69232e9024f</payerref>
<number>4263970000005262</number>
<expdate>1025</expdate>
<chname>James Mason</chname>
<type>VISA</type>
</card>
<storedcredential>
<sequence>subsequent</sequence>
<srd>3wz43jaZBKyiTgec</srd>
</storedcredential>
<sha1hash>85fbaf68bb0e4fccd634facf6592b0677489709e</sha1hash>
</request>Once you’ve completed the process of authenticating and storing the cardholder’s details, you can now proceed with charging the stored details.
When setting up the receipt-in request, if you don’t include the COF fields, we will populate them for you. If you would like to manage these fields yourself, see our Credential On File article.