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.

Subscriptions Create Transaction Flow

1. Customer checks out and initiates a payment of $100.
2. You send the Create Transaction Request with type:pull and recurring:true.
3. TabaPay sends the transaction request to the card network.
4. Network returns with an approved amount of $100.
5. TabaPay sends Create Transaction Response.
6. You present the approved payment to the customer.
7. The recurring charge tiggers again on a monthly basis.

Properties of Subscriptions

Subscriptions payments include both Recurring transactions and unscheduled transactions that would

Recurring Transactions

Unscheduled Card on File

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:
  • Address Verification Service
  • Account Name Inquiry Service
  • 3D Secure
  • CVV2 Check
• 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

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.

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 recurringData in 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.

1. Query Card: TabaPay Client performs Query Card and checks for:

   1. ANI: Add ?ANI+AVS as a query parameter in the Query Card endpoint.
   2. AVS: Add ?AVS as a query parameter in the Query Card endpoint.
   3. CVV: Include the 3-4 digit security code in the securityCode body parameter.

2. 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.

Merchant-Initiated Transaction

MIT: Use the recurring field, and the recurringData array.

Recipes

For more CIT-MIT examples, refer to Merchant Initiated Transactions (MIT).