Recurring Payments Technical Overview

Recurring Payments Technical Overview

Many merchants want to be able to process repeated, regular payments against a client's direct debit account or credit card. This can be achieved by the merchant initiating repeated transactions using the same account or card details. Using one of our Recurring Transactions models, however, achieves the same outcome with one or more of the following benefits:


  • ability to use stored account or credit card details
  • ability to send one setup which details when regular transactions should take place
  • ability to link a set of recurring transactions associated with an account for reporting purposes
  • ability to flag credit card transactions as Recurring Transactions such that the expiry date is not relevant

Note that Recurring Transactions is also known as Continuous Authority, where the end user has authorized continued debits against their account or credit card.

Range of models available

MasterCard Payment Gateway Services have provided different models for processing Recurring Transactions to suit different merchant's requirements. Click on the links for details on how to integrate with these services.

  1. Direct Debit transactions

    • Recurring Transactions (fire & forget)

  2. Credit Card transactions

    • Recurring Transactions(fire & forget)

    • Historic Recurring Transactions 
      (historic txns refer to card details of initial setup)

    • Capture method Recurring Transactions 
      (normal credit card txn processed using RT MID)

Recurring Transaction features and restrictions

There are different features/restrictions of Recurring Transactions (RT) depending on which model you use: Direct Debit or one of the Credit Card models. For credit card transactions acquiring banks have special treatment for transactions flagged as RT, and there are restrictions such as

  • whether your acquirer supports RT

  • whether your acquirer needs you to have a separate Merchant ID (MID) for RT txns

  • the supported card schemes

  • the transaction types that can be used (refunds are not applicable)

  • the first transaction should be processed in your normal environment (Mo/To or e-commerce) and include a valid expiry date

  • subsequent transactions should be flagged as RT and allow an expired card to be used

For all models you have to have an account set up with a client ID (VTID), but some models also require you to be registered with MasterCard Payment Gateway Services for that service and/or have specific TIDs set up before you can use RT.

Some models have a concept of an account, where a setup transaction must be sent first. This setup transaction stores the account or card details for future use, and may detail when regular transactions should take place automatically or initiate a bank transaction immediately. Models that use an account have a specific section of Reporting that can be used to view the history of transactions associated with a particular account.


We recommend that you acquire a test account on the testserver and arrange for it to be set up to match the requirements of your proposed production system in order to fully test all the features you will be using.

Testing on the production servers is not recommended and restrictions may be applied in the future.