Subscription Engine. Version: 1.9 (a) Published: 1 August 2017

Transcription

1 This document describes how the Secure Trading Subscription Engine manages recurring payments through the Secure Trading Payment Platform. Version: 1.9 (a) Published: 1 August /08/2017

2 Table of Contents 1 Introduction Requirements Process Overview Authorisation and Subscription Requests Subscription Fields Detailed Example Additional Notes End of month subscription payments Declined authorisation Subscription active field D Secure and subscription payments Accepted payment types Direct Currency Conversion (DCC) About MyST Expiry dates Further Information and Support Secure Trading Support Secure Trading Sales Useful Documents Frequently Asked Questions Secure Trading Limited August 2017 Page 2 / 10

3 1 Introduction This document provides an overview of how the Secure Trading Subscription Engine manages recurring Subscription payments through the Secure Trading Payment Platform (STPP). When submitting Subscription Requests to STPP, the information passed will instruct the Secure Trading Subscription Engine to schedule additional continuous authority transactions to be processed at designated intervals. Please note that Secure Trading also allows merchants to manually perform Recurring Payments (also known as Tokenisation) through our API. For merchants using our XML interface, please refer to our Recurring Payments document. 1.1 Requirements The following requirements must be met to process Subscriptions Secure Trading You will need to have an account with Secure Trading. For more information, contact our Sales team, details of which can be found in section 4.2 Secure Trading Sales Acquiring Bank In order to process Recurring Payments a Recurring merchant number is required from the acquiring bank. Please check with your acquirer if a new merchant number is required to be able to process this type of payment, or if your existing merchant number is able to process recurring payments. We strongly recommend that you test your Subscription integration using your Secure Trading test account before going live. Secure Trading Limited August 2017 Page 3 / 10

4 2 Process Overview This section of the document outlines how Subscriptions are set up in the Secure Trading Subscription Engine and how payments are processed at scheduled intervals. The process starts when a Subscription Request is sent to STPP. 2.1 Authorisation and Subscription Requests The request sent to Secure Trading, in order to schedule recurring payments, is made up of two sections. 2.2 Subscription Fields An Authorisation (AUTH) Request section, which contains billing and payment details that Secure Trading will pass on to the acquiring bank, in order to process the first payment. A Subscription Request section, which contains details that Secure Trading will use in order to schedule recurring payments in the Subscription Engine, using the same billing and payment details from the Authorisation. Here is a summary of the Subscription fields that will be submitted in a Subscription Request to the Subscription Engine, as shown in the example in section 2.3 Detailed Example. For full technical specifications of these fields, please refer to the relevant document for your chosen Secure Trading solution (see section 4.3 Useful Documents): STPP Subscriptions and Payment Pages document For information on submitting Subscription Requests using the Payment Pages. STPP Subscriptions XML Reference For information on submitting Subscription XML Requests to Secure Trading using either the STAPI client or Web Services. Fields begin date unit frequency Comment The date on which the first Subscription payment will be processed. In this example we use a begin date of: Note: This would be the second payment to be processed, after the initial Authorisation has been processed. This is the unit of time to use, e.g. DAY, MONTH. In this example we use a unit of: MONTH This is the number of units that should occur before the next Authorisation is processed. It represents the gap between each payment in a Subscription. E.g. If unit = DAY and frequency = 7, an Authorisation will be processed every 7 days. In this example we use a frequency of: 1 This represents the position of the last payment in a series of Subscription payments. Once this number has been reached, no further payments will be processed. final number e.g. If a final number = 12, no further Authorisations will be processed after an Authorisation Request with number = 12. In this example we use a final number of: 3 Note: To process payments indefinitely, you would enter the value as 0. Secure Trading Limited August 2017 Page 4 / 10

5 2.3 Detailed Example Once a Subscription Request has been sent to STPP, the Subscription Engine behaves as outlined in the example, below. In the following example, we will schedule recurring payments in the Secure Trading Subscription Engine, so the merchant will be receiving 10 a month from the customer, with payments being processed on the 6 th day of each month, for three consecutive months. Diagram Key Please refer to this key when following the example on the following page. This is the date of the event. Step 1) January 6 th (Subscription Engine) 1/3. AUTH Processing (Status 0 ) 2/3. SUBSCRIPTION Pending 3/3. SUBSCRIPTION This is the current settlestatus of the Authorisation. This is the current state of the Subscription. This is the Subscription number and final number. e.g. 1/3 refers to the 1 st payment out of 3. This is the requesttype of the payment. The Subscription number is the position of the current payment within the Subscription Series, when shown as [number / finalnumber]. E.g. 1/3 refers to a Subscription number of 1 and a finalnumber of 3. Secure Trading Limited August 2017 Page 5 / 10

6 Step 1) 6 th January Request Submitted to Secure Trading Customer Merchant begindate = unit = MONTH frequency = 1 finalnumber = 3 amount = 1000 Processes the Authorisation request. Automatically schedules the pending subscription payments. The merchant submits a request to the Secure Trading Subscription Engine. Secure Trading sends the information contained within the Authorisation section of the request to authorise the initial payment. Once the payment has been authorised, Secure Trading uses the information in the Subscription section of the request, in order to schedule future payments in the Subscription Engine. Secure Trading will indicate whether or not the request was successful. If the Authorisation Request declines or receives an error, no future payments are scheduled. At the end of Step 1, if the authorisation is successful, there will be three transactions in the Secure Trading Subscription Engine: The initial Authorisation (AUTH) Request. Two SUBSCRIPTION transactions, which are scheduled for the 6th February and the 6th March, respectively. Step 1) January 6 th (Subscription Engine) 1/3. AUTH Processing (Status 0 ) 2/3. SUBSCRIPTION Pending 3/3. SUBSCRIPTION Step 2) 7 th January First AUTH settles and SUBSCRIPTION becomes Active Step 2) After the first AUTH transaction has been settled (Status 100 ) by the acquirer, the first SUBSCRIPTION transaction is updated automatically to become Active 2/3. January 1/3. AUTH Settled (Status 100 ) 7 th 2/3. SUBSCRIPTION Active 3/3. SUBSCRIPTION Secure Trading Limited August 2017 Page 6 / 10

7 Step 3) 6th February First SUBSCRIPTION becomes an AUTH Request The first SUBSCRIPTION payment (the second payment in the series 2/3) is processed as an Authorisation Request and sent to the acquirer for authorisation. Note: This new AUTH transaction can be updated as with any other normal AUTH transaction. Step 3) February 1/3. AUTH Settled (Status 100 ) 6 th 2/3. AUTH Processing (Status 0 ) 3/3. SUBSCRIPTION - Active The next SUBSCRIPTION transaction in the sequence becomes Active. Step 4) 7th February The second AUTH settles Step 4) The first scheduled SUBSCRIPTION transaction (the second payment in the series 2/3) has been settled. At this stage, two payments have been settled for the Subscription. February 1/3. AUTH Settled (Status 100 ) 7 th 2/3. AUTH Settled (Status 100 ) 3/3. SUBSCRIPTION - Active Step 5) 6th March Second SUBSCRIPTION payment becomes an AUTH Request The second scheduled SUBSCRIPTION transaction (the third payment in the series 3/3) is processed as an Authorisation Request and sent for authorisation to the acquirer. Notice how a fourth SUBSCRIPTION payment (highlighted on the right in blue) has been scheduled (for the 6 th April), despite the merchant only requesting for three payments initially (finalnumber = 3). Step 5) March 1/3. AUTH Settled (Status 100 ) 2/3. AUTH Settled (Status 100 ) 6 th 3/3. AUTH Processing (Status 0 ) 4/3. SUBSCRIPTION Active This additional SUBSCRIPTION is created in order for any further updates to be made to the Subscription (e.g. to extend a Subscription to a new end date). This is shown while the final payment is being processed, and will remain even after final payment has settled. Secure Trading Limited August 2017 Page 7 / 10

8 Step 6) 7th March Third AUTH settles The final scheduled SUBSCRIPTION transaction (the third payment in the series 3/3) is settled, and all scheduled payments have been processed for the customer. Step 6) March 1/3. AUTH Settled (Status 100 ) 2/3. AUTH Settled (Status 100 ) 7 th 3/3. AUTH Settled (Status 100 ) 4/3. SUBSCRIPTION Active Step 7) 6th April The Final State Once all the scheduled payments have been processed for the Subscription, it will be in the final state, as shown on the right. The Subscription Number will be shown as 4/3 and shown as Active, with no further payments processed. This will remain in its current state ( Active ), to allow further updates to occur for the Subscription (e.g. to extend the period of the Subscription for another year). Step 7) April 1/3. AUTH Settled (Status 100 ) 2/3. AUTH Settled (Status 100 ) 6 th 3/3. AUTH Settled (Status 100 ) 4/3. SUBSCRIPTION Active Secure Trading Limited August 2017 Page 8 / 10

9 3 Additional Notes This section contains additional information you will need to consider when implementing subscriptions. 3.1 End of month subscription payments Subscription payments can be processed monthly from the date of the initial payment. If the date of the initial payment is after the 28 th of the month, all following subscription payments are scheduled for the 28 th of each month. This is to prevent issues for subscription payments on months that have fewer days than others. 3.2 Declined authorisation It is not possible to schedule recurring payments in the Subscription Engine, if the first Authorisation request was declined by the acquirer. 3.3 Subscription active field A Subscription transaction is initially set as 2 - Pending and is only updated to 1 - Active once the initial payment has settled. This is to prevent Subscription payments being processed if the initial transaction has not completed and also to ensure fraud*, duplicate* and settlement checks are carried out. The subscription active field can be manually overridden using MyST (see section 4.3 Useful Documents). Please note that updating a Pending Subscription to be Active will ignore the results of any fraud*, duplicate* or settlement checks on the initial Authorisation. *Fraud and duplicate checks are not enabled by default on new Secure Trading accounts. Please contact Secure Trading Support for further information D Secure and subscription payments The initial Subscription payment can be processed using 3-D Secure, where the customer will be required to authenticate their transaction. All subsequent transactions will be processed as standard Authorisations (non 3-D Secure). 3.5 Accepted payment types Only Visa, Mastercard and AMEX branded cards can be used for processing subscription payments (excluding Maestro). 3.6 Direct Currency Conversion (DCC) The Secure Trading Subscription Engine does not currently support Dynamic Currency Conversion (DCC). 3.7 About MyST MyST is a password protected online management area which allows all Secure Trading merchants to monitor their transactions and perform other management on their account(s). You can you use the MyST system to view and update Subscriptions. This is explained in detail in the STPP MyST User Guide (see section 4.3 Useful Documents). 3.8 Expiry dates Please ensure that the expiry dates on your active subscriptions are valid and up-to-date as some issuers may decline cards with outdated card expiry dates. These can be updated by using MyST or by performing a Transaction Update request through our API. Secure Trading Limited August 2017 Page 9 / 10

10 4 Further Information and Support 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 The documents listed below should be read in conjunction with this document: STPP XML Specification Documentation This document outlines fields used in XML Requests and Responses by Secure Trading. STPP Subscriptions XML Reference This document outlines the structure of Subscription XML Requests and Responses. STPP Subscriptions and Payment Pages This document outlines how to process Subscription requests using the Secure Trading Payment Pages solution. STPP MyST User Guide This document outlines how to use MyST to monitor your transactions and manage your account. STPP Payment Pages Guide This document outlines how to process payments using the Secure Trading Payment Pages solution. 4.4 Frequently Asked Questions Please visit the FAQ section on our website ( Secure Trading Limited August 2017 Page 10 / 10