Recurring billing is a mechanism that allows a business to receive ongoing payments, but get card information from the customer only once. It is similar to a subscription system in many ways but doesn’t necessarily involve the pricing tiers that a subscription system may include. Recurring billing is helpful for business owners because it guarantees a predictable cash flow, and the entirely automated setup saves time and resources. A good recurring billing system can be implemented with the support of the right subscription management tools to tackle challenges like payment failures and fraudulent payments.

Definition and use of tokens


 Recurring Payments are based on tokenization. After the initial transaction, Accept will generate a token referring to the transaction. When performing subsequent transactions, you need to refer to this token to allow the card to be captured without sending all the card information again. Otherwise, it is not considered as a hash value. Instead, it is a randomly generated sequence, It is the merchant's responsibility to store tokens in a secure way in their systems and restrict access to data on a need-to-know basis. The merchant undertakes not to store tokens on a frontend system exposed to the internet or directly on mobile devices.

The tokens used in Accept have identical formats. However, they are not interchangeable. Instead, the token in question can only be used for the same recurring type (Moto Payment) it was initially created for.

Technical Procedurals:


Accept gives you the capability of saving your customer's card token, this could be done by following the steps mentioned below:

The Merchant needs to share with us his username and MID you can get it from your accept dashboard to Create a Moto test integration ID.

1- Saving a card with 1st purchase:


* Perform the first 3 steps as shown in the web documentation using your card online integration _id.

* Open IFrame for the client, mark save the card as checked, and hide the field (share with us your IFrame id and we'll edit it)

* After the transaction, the transaction processed callback will be invoked with the transaction body (step5) and a token             object

* Mapping of user - token will be done on the backend

2-Paying with saved card:


* Perform the first 2 steps as shown in web documentation

* Perform step 3 as shown in web documentation using your moto integration _id the field in JSON body "token": "token identifier"

Pay using token just like documentation, you will send the request and you will find in response redirection URL, you will         redirect your customer to it, this will be the OTP       page.

Transaction processed callback will be invoked with transaction body (step5)