Subscriptions
🏁 New To TabaPay? Start Here
1. Learn
If you are just learning about TabaPay you can begin at Getting Started, and About TabaPay.
2. Chat
To Make your first API Call, you will first need access to Sandbox. Talk to sales to discuss your use case or get help at [email protected].
3. Test
Once you have access to sandbox from TabaPay Support, look at some code samples with recipes or feel free to post your questions in the developer forum.
Payload Should Be Compact
Each API request body should be formatted in compact JSON when sending a request to the TabaPay API.
Note: If you don’t have access to sandbox, please reach out to [email protected] .
Subscriptions is a general use case and payment model where a customer automatically pays on a recurring basis for specified period for access to a product or service.
TabaPay Clients offering Subscriptions act on a pre-agreed standing instruction from the cardholder for the provision of goods or services.
TabaPay's payment methods and features allow you to facilitate subscriptions payments while meeting the needs of the end customer with flexible options. Grow your payments with TabaPay's wide network of cards, bank payments, and wallets. You can card accept payments and collect information safely using the Dynamic iFrame, or if you have a preexisting PCI compliant payment flow, you can integrate solely with the TabaPay API.
Get Enabled for Subscriptions
Interested in offering Subscriptions to your customers? Contact us: email [email protected] to get started.
Use Cases
- SaaS and Digital Services: Recurring charges for software-as-a-service platforms or digital services like streaming media, cloud storage, or productivity tools.
- Utility Payments: Simplify regular utility bill payments, such as electricity, water, or internet services, through automated subscription billing.
- eCommerce: Enable recurring payments for digital or physical goods ensuring uninterrupted supply of any product.
Properties of Subscriptions
Subscriptions payments include both Recurring transactions and unscheduled transactions that would
Recurring Transactions
| What | Details |
|---|---|
| Description | A transaction in a series of transactions that use a stored payment credential and that are processed at fixed, regular intervals (not to exceed one year between transactions), representing cardholder agreement for the merchant to initiate future transactions for the purchase of goods or services provided at regular intervals. |
| Maximum Timeframe between Original Transaction and MIT | The timeframe is governed by a contract between the consumer and the merchant for that specific recurring relationship. |
| Relevant Merchant Segments | Any merchant category can submit Recurring Payment transactions. |
| Example | A magazine publisher charges cardholder for monthly subscription. |
Unscheduled Card on File
| What | Details |
|---|---|
| Description | A transaction using a stored credential for a fixed or variable amount that does not occur on a scheduled or regularly occurring transaction date, where the cardholder has provided consent for the merchant to initiate one or more future transactions. |
| Maximum Timeframe between Original Transaction and MIT | The timeframe is generally undetermined, as payment is prompted by a pre-agreed event between the cardholder and merchant in the contract governing their relationship |
| Relevant Merchant Segments | Any merchant category can submit unscheduled COF transactions |
| Example | An example of such transaction is an account auto-top up transaction |
MIT and Subscriptions
Merchant Initiated Transactions (MIT) Requirements
Subscription clients with a standing agreement with the cardholder must read TabaPay Merchant Initiated Transaction (MIT) framework to ensure optimal approval rates with issuers.
Prior to the introduction of the MIT framework, it was not possible to identify transaction intent or the cardholder’s active participation. A merchant could initiate a transaction, but without the cardholder’s active participation, they could not provide authentication elements (such as CVV2) to the issuer. Consequently, issuers often declined MITs.
Further, the introduction of payment tokens required authentication data elements (i.e., cryptogram) for every transaction. Merchants in these scenarios could not perform transactions when the cardholder was not actively participating. In the absence of a standard framework these transactions failed, were declined, or in some instances were processed inconsistently across geographies.
The MIT framework:
- Introduces a global standard to identify transaction intent and whether a transaction is
merchant-initiated—i.e., a cardholder is actively participating and available for
authentication. It also enables merchants, acquirers, and issuers to link a series of related
transactions together. - Enables consistent MIT processing.
- Provides transaction transparency, resulting in higher authorization rates and improved
cardholder experience. - Allows merchant-initiated, token-based transactions to be processed without
authentication data elements. These transactions may otherwise fail. - As MITs are performed as a follow-up to a cardholder-initiated transaction (CIT), merchants
and acquirers accepting CITs with a payment token must comply with the MIT framework to
enable successful processing of the subsequent MITs they perform.
Best Practices for Subscriptions
TabaPay recommends the following best practices that our TabaPay Clients are recommended to follow when offering Subscriptions.
Setting up Subscriptions
- To set-up a recurring charge, obtain consent from the cardholder and include the following:
- Transaction amount or minimum or maximum transaction amounts, if the transaction may vary
- Frequency of the recurring charges
- Duration of time that cardholder permission is granted
- Retain a copy of the cardholder’s consent for the duration of the recurring services and provide a copy if requested by the issuer.
- Obtain relevant card payment details to complete the transaction such as:
- Cardholder name and billing address
- Card type/Account number
- Card expiration date
- Card Verification Value 2 (CVV2)
- Obtain an authorization and a valid approval:
- Include the expiration date to TabaPay
- Ensure you use TabaPay Account Updater when storing cards on file for the purposes of Recurring transactions.
- Use TabaPay Shield to verify the legitimacy and accuracy of the cardholder and card:
- Check the authorization response back from TabaPay and take the appropriate action. Based on the response, if you receive a decline response for any reason other than “lost”, “stolen”, or “pick-up”, you may retry
the authorization if it is cost-effective for your business to do so. Note: An authorization may
be retried up to a maximum of four times within 16 calendar days of the original request. If an
approval response is not received, the transaction is exposed to authorization related disputes
and you may want to consider asking for a different card. - Familiarize yourself with Network requirements around Transaction Processing and Excessive Retries
Transaction Integrity and Network Fees
Ensure this page is read and the requirements are followed.
- Ensure that all applicable state or federal laws are followed when establishing this agreement
with the cardholder. TabaPay recommends the merchant consult with their own legal counsel.
Ensuring Customer Satisfaction
- Provide your customers with a toll-free phone number, an e-mail address, and/or easy to find (and use) online procedures for cancelling recurring transactions.
- Train your sales and customer service staff on the proper procedures for processing recurring
transactions, as these transactions are particularly customer service sensitive. - Fully disclose all necessary transaction terms and conditions.
Follow MIT Framework
Ensure your technology teams understand and code to the Merchant Initiated Transactions (MIT) (MIT) framework for recurring transactions.
How to Cancel Recurring Transactions
- Check customer logs daily for cancellation or non-renewal requests related to recurring transactions. Take the appropriate action and comply in a timely manner. Notify the customer that his/her recurring payment account has been closed.
- Process all credits promptly. If a cancellation request is received too late to prevent the most recent recurring charge from posting to the customer’s account, process the credit and notify the cardholder.
- Flag transactions that exceed preauthorized amount ranges. Notify customers at least ten days in advance of submitting a recurring transaction billing.
- Check customer logs daily for customer complaints, especially those relating to transaction amounts or failure to notify customers in advance of a recurring transaction that exceeds the preauthorized amount range. Follow up with customer.
- Provide the cardholder with the recurring transaction cancellation number
How to Handle Recurring Transaction Customer Dispute Chargebacks
| If | Then |
|---|---|
| The cardholder claims to have cancelled the recurring transaction. | Send evidence that a credit was issued to the cardholder for the disputed amount or provide information regarding the credit issued (e.g., the date the credit was issued, the amount of the credit, the credit transaction number). |
| A credit has not yet been processed to correct the error | Accept the dispute but do not process a credit as the dispute has already performed this function |
| You have no record that the cardholder cancelled the transaction. | Resubmit the dispute to your acquirer. |
| The customer claims he was billed for the service after he cancelled. | You may need to supply proof that the bill in question (i.e. the “final billing”) covered services used by the customer between the date of the customer’s prior billing statement and the date the customer requested cancellation. |
| The customer has cancelled the recurring payment transaction and there is a final payment still to be charged. | Notify the cardholder directly to discuss final payment |
| The cardholder claims that the recurring transaction amount exceeded the preauthorized dollar range. You notified the cardholder at least 10 calendar days prior to the transaction date; the cardholder did not dispute the transaction that was posted to his/her account. | Send evidence of your customer notification. |
Subscriptions Create Transaction Flow
- Customer checks out and initiates a payment of $100.
- You send the Create Transaction Request with
type:pullandrecurring:true. - TabaPay sends the transaction request to the card network.
- Network returns with an approved amount of $100.
- TabaPay sends Create Transaction Response.
- You present the approved payment to the customer.
- The recurring charge tiggers again on a monthly basis.
Payment Features
You can use different payment features for an improved customer experience with subscriptions.
MIT is Required for Subscriptions
When completing a subscriptions payment, you are required to include data for a Merchant Initiated Transaction (MIT) , which is preceeded by a Customer Initiated Transaction CIT.
| Payment Feature | Benefit | Recommendation | CIT | MIT |
|---|---|---|---|---|
| Merchant Initiated Transaction Framework | Merchant Initiated Transactions (MIT) is required for all subscriptions using cards. MIT allows you to store a payment credential-on-file and use it for subscriptions, or on-going payments. | Required for recurring transactions using an Original transaction (per MIT framework) | Yes | Yes |
| Partial Authorization Service | When customers do have enough funds to cover the full transaction amount, Partial Auth provides an alternative to declining a transaction by accepting a partial balance. Participating issuers return a response with an approval for a portion of the original amount requested, enabling the remainder of the transaction amount to be paid by other means using split-tender functionality. | Highly Recommended | Yes | Yes |
| 3D Secure | Three-Domain Secure or 3DS is a messaging protocol merchants use to authenticate their customers’ card information when processing card-not-present (CNP) e-commerce, or mobile purchases, and payments. By enhancing authentication, 3DS helps prevent fraud and provides an additional layer of security for CNP credit card and debit card transactions.This service is provided by all four major card networks. | Highly Recommended | Yes | - |
| Account Name Inquiry | To help address growth in account takeover fraud and authorized push payment scams, market demand, and increasing concern from governments and regulators, card networks have introduced Account Name Inquiry (ANI) functionality. It enables an account cardholder’s name to be checked against the name held by their Issuing bank. | Highly Recommended | Yes | - |
| Address Verification | Address Verification Service (AVS) is a fraud prevention mechanism that reduces fraud and chargebacks. The service verifies if the card issuer recognizes the address provided by a cardholder. The results of the verification will help you determine whether to accept or decline a particular transaction or take further action. AVS is effective to both reduce fraud and reduce chargebacks. | Highly Recommended | Yes | Yes |
| CVV2 Verification | CVV Verification is a tool that helps verify if the cardholder has possession of the physical card. While it is not effective against lost or stolen card fraud, it is an additional check beneficial in e-Commerce channels since the Card security code is only printed on a physical card and is not available anywhere else. | Highly Recommended | Yes | - |
| Apple Pay and Google Pay Tokens | Can be used as additional payment methods offered. | - | - | - |
| TabaPay Account Updater | TabaPay Account Updater (TAU) is a service that enables TabaPay clients who store cards on file with TabaPay to get them updated with the card networks to ensure they reflect the information available at the card issuer. This in turn addresses our client's need to run recurring payments and MIT on the cards on file without requiring their customer's to update them when the payment credential at the issuer has been updated. TAU significantly reduces customer friction, and meets the need to collect an updated card expiry date or payment credential since TabaPay automatically updates cards you store on file with us. | Highly Recommended at the Client level | - | - |
| TabaPay Tokens | TabaPay stores and manages payment cards and bank accounts securely for you. We call this TabaPay Tokens (aka TabaPay Vault). This capability allows you to be an efficient fintech while letting us manage the burden of PCI-DSS compliance for you. TabaPay takes on the complexities of storing these payment instruments safely and securely, while you to focus on your core value proposition! For every payment card or bank account, TabaPay validates the incoming payment instrument and stores them as an Account ID. This Account ID is what is provided back to you, so you do not have to manage the 16-digit payment card number or bank account. You will be able to utilize the Account ID within our Unified API (Create Transaction API) to Push and Pull. | Highly Recommended at the Client level | - | - |
How the Create Transaction API Works for Subscriptions
1. Prerequisites
Before connecting to then endpoint, ensure your IP is whitelisted as mentioned in step 4 of Integrating with TabaPay.
CIT-MIT Data Required
You must include the
recurringDatain the API including the network ID and CIT-MIT indicators.
For this pull transaction, you will populate information differently for a card or bank payment within the Source Account object.
To enhance security, you can use TabaPay Tokens to generate unique IDs for card or bank details. Learn how Card Query APIs can use AVS to provide insights into how fraud controls influence transaction outcomes.
All requests should be in a compressed format.
2. Create Transaction
Use the Create Transaction with type:pull. Depending on the payment features included, your API request body (parameters) will look different. Refer to the examples below in Recipes.
Cardholder-Initiated Transaction
Here are some recommended indicators to look out for in with the following features.
CIT will use the recurring field, and the recurringData array.
-
Query Card: TabaPay Client performs Query Card and checks for:
-
Create Transaction Request: The TabaPay client submits a Create Transaction Request with the following indicators:
- Partial Auth: Authorize partial payment acceptance with
pullOptions.partial:true - 3DS: Follow the 3DS guide to set up the 3DS workflow.
- TabaPay Token: Include the Account ID, or Source Account ID you created with Create Transaction.
- Partial Auth: Authorize partial payment acceptance with
Merchant-Initiated Transaction
MIT: Use the recurring field, and the recurringData array.
Recipes
For more CIT-MIT examples, refer to Merchant Initiated Transactions (MIT).
Updated about 17 hours ago