Credentials on File. Published: 26 April

Transcription

1 Published: 26 April

2 Table of Contents 1 Credentials on File Benefits Processing CoF Merchant Initiated Transactions Processing an MIT Additional Notes on MIT. 7 3 Examples of using CoF and MIT in requests Further information Secure Trading Support Secure Trading Sales Useful Documents Frequently Asked Questions 9 Secure Trading Limited April 2018 Page 2 / 9

3 1 Credentials on File A stored credential is information (including, but not limited to, an account number or payment token) that is stored in order to process future transactions. The process of storing credentials for future use is known as Credentials on File (CoF). Visa and Mastercard have mandated that you must obtain cardholder consent before storing card details for future use, and that these must be flagged at the time of the first authorisation, by submitting the credentialsonfile field in your requests. You must also flag any subsequent payments that are utilising previously-stored credentials, by including the credentialsonfile field in these requests. Examples of situations where the CoF mandate applies: Processing an account check or authorisation request, where card details are to be re-used later. Processing a re-authorisation. Processing regular recurring payments. Refer to section 3 for example use-cases. This mandate comes into effect on 30th April 2018, but we encourage you to make the required changes as soon as possible so you are ready. Requests processed before the cut-off are not affected, but new requests after the cut-off must pass through the credentialsonfile field. While this is only mandated by Visa and Mastercard, you can still submit these values in all your requests, and we will ignore them for other payment types. 1.1 Benefits Identifying transactions as using CoF provides the following advantages: Increases the likelihood of transaction authorisation and settlement. Greater transparency and improved experience from the customer s perspective. Issuers are less likely to use the absence of a security code as a reason to decline a transaction. Secure Trading Limited April 2018 Page 3 / 9

4 1.2 Processing CoF Initial payment request MyST If using the Virtual terminal or processing an ST PayMe , set Credentials on file to 1 Credentials stored for re-use, using the drop-down provided Payment Pages Include field credentialsonfile in the POST to Secure Trading. Set the field to value 1. If using Payment Pages, you will need to update how you calculate your site security hash, as credentialsonfile is a new default site security field XML In the AUTH or ACCOUNTCHECK request, include field operation/credentialsonfile, with value set to 1. <operation> <credentialsonfile>1</credentialsonfile> </operation> JSON In the AUTH or ACCOUNTCHECK request, include field credentialsonfile, with value set to 1. "credentialsonfile": "1" Additional Notes If the parent response indicates an error occurred (error/code 0 ), the credential cannot be considered a stored credential, and you must not use these card details in any subsequent payments. Secure Trading Limited April 2018 Page 4 / 9

5 1.2.2 Later payment using CoF MyST When performing a re-auth, set Credentials on file to one of the following: 2 - Scheduled payment using stored credentials 3 - Unscheduled payment using stored credentials Payment Pages Not applicable. Process a re-auth using MyST or via our API solutions (XML / JSON) XML In the AUTH request, include field operation/credentialsonfile, with value set to one of the following: 2 For scheduled payments using stored credentials 3 For unscheduled payments using stored credentials <operation> <credentialsonfile>2</credentialsonfile> </operation> JSON In the AUTH request, include field credentialsonfile, with value set to one of the following: 2 For scheduled payments using stored credentials 3 For unscheduled payments using stored credentials "credentialsonfile": "2" Secure Trading Limited April 2018 Page 5 / 9

6 2 Merchant Initiated Transactions Transactions processed by the merchant are called Merchant Initiated Transactions (MIT). Visa mandate that you must provide a reason for processing unscheduled payments, using stored credentials. This does not apply to Customer Initiated Transactions (CIT). This is achieved by submitting a new field in the AUTH request called initiationreason, containing a single character that maps to a reason as to why the payment is being processed. This mandate comes into effect on 30th April 2018, but we encourage you to make the required changes as soon as possible so you are ready. These are the values we currently support: "A" Re-authorisation "D" - Delayed Charges "S" - Resubmission "T" - Account top up "X" - No-show (for a hotel booking) (These values are defined by Visa, and are subject to change) While this is only mandated by Visa, you can still submit these values in all your requests, and we will ignore them for other payment types. Secure Trading Limited April 2018 Page 6 / 9

7 2.1 Processing an MIT MyST When performing a re-auth, set Initiation reason to one of the available values, as listed above Payment Pages Not applicable. Process the payment using MyST or via our API solutions (XML / JSON) XML In the AUTH request, include field operation/initiationreason, setting the value to be one of those listed above. <operation> <initiationreason>s</initiationreason> </operation> JSON In the AUTH request, include field initiationreason, setting the value to be one of those listed above. "initiationreason": "S" 2.2 Additional Notes on MIT The MIT initiation reasons described within this document do not apply to scheduled / regular payments (e.g. subscriptions), as the customer should have already agreed to the subscription and understand why payments are being processed. The MIT initiation reasons do not apply to transactions regarded as Customer Initiated Transactions (CIT). Secure Trading Limited April 2018 Page 7 / 9

8 3 Examples of using CoF and MIT in requests Please refer to the table below for example use-cases of the CoF and MIT fields to be included when processing transactions: Use case CoF value (section 1) MIT value (section 2) First payment in a sequence of recurring payments Payment where card details are to be stored for future payments Previously-agreed regular subscription payments Customer requests that funds are added to their account 1 Don t send 1 Don t send 2 Don t send 3 Don t send Re-auth initiated by the customer 3 Don t send Unscheduled re-authorisation processed by the merchant 3 A Delayed charge using stored credentials 3 D Re-submission of payment 3 S Unscheduled account top-up, processed by the merchant 3 T No-show 3 X Secure Trading Limited April 2018 Page 8 / 9

9 4 Further information This section provides useful information with regards to documentation and support for the merchant s Secure Trading solution. 4.1 Secure Trading Support If you have any questions regarding integration or maintenance of the system, please contact our support team using one of the following methods. Method Details Telephone +44 (0) Fax +44 (0) support@securetrading.com Website Secure Trading Sales If you do not have an account with Secure Trading, please contact our Sales team and they will inform you of the benefits of a Secure Trading account. Method Details Telephone Telephone (Int l) +44 (0) Fax +44 (0) sales@securetrading.com Website Useful Documents Refer to the following URL for other useful documents: Frequently Asked Questions Please visit the FAQ section on our website ( Secure Trading Limited April 2018 Page 9 / 9