🏁 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] .

What is Debt Repayment?

Debt Repayment is a general use case and payment acceptance process to return borrowed funds from the borrower to the lender. In short, they are transactions that are used to pay off debt. For example, a payer can perform a card payment to pay off the balance of their credit card.

Debt Repayment Merchant or Lender

Debt Repayment Merchants and Lenders are one in the same that have either:

• Loaned money to a consumer for the purpose of purchasing; e.g. vehicle, residence, college education; or
• Issued a credit card to a consumer with the option to carry a balance.

👍

How do you participate in Debt Repayment

Interested in offering Debt Repayment to your customers? Contact us: email [email protected] to get started.

Eligibility

📘

Only debit and prepaid products may be accepted for debt repayment transactions.

Debt repayment is limited to merchant types with one of the following categories:

• Financial Institution: Financial institutions Merchandise, services, and debt repayment
• Non Financial Institution: Foreign currency, money orders (not wire transfer), stored value card/load,
  travelers cheques, and debt repayment

Benefits

Potential benefits to debt repayment acceptance include improving cash flow, streamlining operations, and increasing customer satisfaction.

• Improved Cash Flow: By accepting Visa payment cards, transactions are expediently processed and settled, and funds are made available quickly. This is especially beneficial when dealing with large payments, and when considering extended time frame for cheques clearance. When adhering to simple authorization procedures, you can generally expect to receive guaranteed payment from your acquirer within 24 to 48 hours, as opposed to the five days it can take with cheque processing.
• Streamlined Operations and Customer Appeal: Cash and cheque acceptance involves operational costs, risk of loss or returns. Accepting Visa payments can save time and effort:
  • Automatic recurring payments: Enabling an automatic recurring payment option will decrease time spent on collecting late payments or returned cheques.
    Additionally, customers often prefer automated payments, as they are efficient and effective and help to ensure they will not miss a due date.
  • Customer trends: Young people in the 24-30 year-old range rely on payment cards for 63 percent of their monthly spending. They want to make payments quickly and easily using the technology at their fingertips rather than manually paying with cheques. Additionally most consumers do not know their routing and transit information to set up ACH payment, while those same consumers know or can easily provide their debit card number.
    • Improved operational efficiency: Realize cost savings by migrating cheque payers to Visa debit and paperless statements, reducing agent assisted calls and migrating calls to Interactive Voice Response. Reduces exception processing due to non-sufficient funds.
    • Guarantee payment against non-sufficient funds: Decrease risk in accepting electronic payments vs. returned cheques.
    • Convenience, control, tracking and flexibility: Widely used in collections and the practice can be expanded.
• Fast Access to Funds: Card transactions are processed and settled quickly, often making funds available within 24 to 48 hours, much faster than alternative payment options.
• Simplified Payment Flows for Increased Revenue: Set up automated recurring payments to reduce late or abandoned payments.
• Better Customer Preferences : Offer flexible payment methods for customers including cards for quick, and easy user workflow.

Use Cases

• Auto Loans: Set up recurring or one-time payments for customers to repay their auto loans using their bank account or card.
• Credit Card Loans: Allow customers to pay off credit card balances or loan amounts linked to credit cards. Provide flexible payment options for scheduled or manual repayments, helping customers reduce interest and maintain good standing with card issuers.
• Personal Loans: Facilitate repayment of personal loans with options to use bank accounts or card.
• Student Loans: Support customers in repaying student loans with automated payment plans or manual payment options.
• Mortgage Payments: Simplify mortgage repayments with scheduled pull transactions from bank accounts.
• Facilitate Third Party Lending: Facilitate funding or enable financing for customers purchasing goods or services through a third-party lender.

Out-of-scope Cases

• Debt that is past statute of limitations and is no longer collectible in a lawsuit, unless the merchant lawfully obtains cardholder’s written agreement to repay the debt in a specified amount.
• Lease payments, where the payer does not automatically obtain ownership at the end of the payment.
• Installment payments (not considered paying off pre-existing debt)
• Delayed payment for goods or services based on terms agreed upon between the cardholder and the seller.

Debt Repayment API Flow

The following diagram represents a Debt Repayment CIT transaction.

1. The borrower initiates a repayment of $100—customer response and inputs payment info.
2. You send the Create Transaction request with type:pull.
3. TabaPay sends the request to the networks.
4. Networks return the request with a success or error.
5. TabaPay returns the API response to you.
6. You display the relevant confirmation(s) to the customer and borrower.

Integration

The following section provides integration details for implementing your use case.

Feature Enablement at TabaPay

• TabaPay clients who wish to integrate with debt repayment must work with their TabaPay representative to enable the feature.
• Please request Partial Authorizations as a Debt Repayment Client.
• No enablement is required for cardholder-initiated vs merchant-initiated transactions.

Payment Features to Consider

Cardholder-Initiated Transaction (CIT) vs Merchant-Initiated Transaction (MIT)

Your use case may often includes a CIT followed by an MIT. In the life of a payment workflow, there can be many CITs depending on how often cardholders update their card information with you.

Implementation Checklist

This checklist serves as a guideline for TabaPay clients interested in implementing this feature and includes, but not limited to, the following:

• Feature enablement of your use case.
• Distinction between Cardholder-Initiated and Merchant-Initiated Transaction
• Cardholder experience & design between CIT and MIT
• Sandbox integration
• Production integration

Cardholder-Initiated Transaction

Include the designated requirement for each listed feature.

1. Customer Initiates Transaction: The TabaPay client’s customer presents their card for a transaction. They initiate a purchase of $100.

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

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

4. Transaction Submission: TabaPay sends the transaction request to the card network (for e.g with the Partial Authorization indicator enabled)

5. Card Network Processing: The card network verifies the transaction and forwards it to the card issuer.

6. Issuer Evaluation: The issuer reviews the transaction and approves the available balance on the card. If the available balance is less than the purchase amount, the issuer returns an authorization response to the card network. This response includes a unique code and the approved partial amount.

7. Network Communication: The card network notifies TabaPay of the partial approval amount.

8. TabaPay Client Notification: TabaPay informs the client of the authorization response.

9. Customer Communication: The TabaPay client identifies the partialAmount field in the response, calculates the difference between the approved partial amount and the total transaction amount, and communicates this information to the cardholder.

10. Cardholder Options: The cardholder has three options:

    1. Provide an Additional Payment Method: Use split-tender functionality to cover the remaining balance.
    2. Cancel the Transaction: Opt not to proceed with the purchase.
    3. Accept the Partial Purchase: Agree to load only $75 into their app account.

Note: This process aims to ensure a smooth and satisfactory experience for the customer. If the customer decides not to complete the sale, the TabaPay client should initiate an authorization reversal for the partial amount.

Merchant-Initiated Transaction

A Merchant-Initiated Transaction (MIT) is based on an existing agreement between TabaPay client and the cardholder. Typically, this agreement is established when the cardholder completes an initial transaction on their own. During this process, the cardholder is provided with all relevant terms and conditions, along with any other necessary information.

Subsequently, TabaPay client can store the networkID from the Create Transaction Response. This identifier is used in future transactions to link merchant-initiated transactions with the original cardholder-initiated transaction, allowing the network and issuers to effectively associate the two.

Here’s a guided flow of Merchant-Initiated Transactions:

1. Lender initiates an MIT repayment of $100 (paid by the customer).
2. You send the Create Transaction request with type:pull and MIT indicators.
3. TabaPay sends the request to the networks.
4. Networks return the request with a success or error.
5. TabaPay returns the API response to you.
6. You display the relevant confirmation(s) to the customer and borrower.

MIT Indicators

1. Execute Transaction on Scheduled Day: On the day of the transaction, the TabaPay client should use the Create Transaction API only if the cardholder has not canceled the transaction. If explicit consent from the cardholder has not been received (whether through cancellation or lack of response), the TabaPay client shall refrain from processing the transaction.
2. Specify Merchant Initiated Transaction: For guidance on integrating Merchant-Initiated Transactions, consult the Visa MIT recipe and MasterCard MIT recipe. It will be important for TabaPay clients to include the networkID field of the original cardholder-initiated transaction.
   1. MITuses the recurring field, and the recurringData array.
      1. See the full list of values on CIT MIT Indicators.
      2. See the full example body parameters within each Recipe.
3. Set Partial Authorization Flag: Set the partial field in pullOptions to true to indicate that partial authorization is requested.
4. Handle Create Transaction Response: If the Create Transaction API response includes the partialAmount field, it indicates that the transaction was partially authorized.

5. Provide Receipt and Cancellation Confirmation:
   1. Send a Receipt: Follow up with a receipt of the transaction, including details of any additional payment methods used for the remaining balance.
   2. Confirm Cancellation: If the transaction is canceled, provide a confirmation of the cancellation to the cardholder.

Best Practices:

• Initial Transaction with Cardholder Present: Conduct the initial transaction with the cardholder present (Cardholder-Initiated Transaction, CIT) so that they can review and agree to all terms and conditions.
• Store & Relay NetworkID: Record the networkID from the initial transaction and use it in the networkID field in pullOptions.recurringData for all subsequent merchant-initiated transactions.
• Advance Notification: Notify cardholders well in advance about upcoming transactions, including details about potential partial authorizations. Use methods such as email, SMS, or in-app notifications
• Internal Staff Training: Train support staff to handle issues related to partial authorizations, including the process for reversing them. Be prepared to void or reverse partial authorizations if needed.
• Review MIT Guidelines: For additional details on merchant-initiated transactions, refer to the guidelines available at: Merchant-Initiated Transactions Overview.

Debt Repayment Implementation Considerations

Transaction Resubmission Requirements

A debt repayment transaction that receives a decline response may not be resubmitted for authorization if any of the
following is true:

• The transaction has already been submitted three times, with each retry resulting in a decline response.
• After more than 14 calendar days from the date of the original decline response.
• The decline response code was one of the following
  • 04 – Pick-up card
  • 14 – Invalid account number (no such number)
  • 41 – Pick-up card (lost card)
  • 43 – Pick-up card (stolen card)
  • 52 – No checking account
  • 57 – Transaction not permitted to cardholder
  • 75 – Allowable number of PIN-entry tries exceeded
  • 78 – Blocked, first used
  • 82 – Negative Online CAM, dCVV, iCVV, or CVV results
    Do not deposit the transaction after a decline response that has met one of the above conditions—regardless of whether an approval response is received.

Transaction Receipt Requirements

A transaction receipt for debt repayment must contain the type of repayment—for example, loan, mortgage, credit card, goods, or services.

Customer Service and Training Requirements

Determine what kind of training is required for customer-support staff.
Staff training is helpful to ensure adherence to acceptance options- for example, setting up recurring payments.

Recipes

Here are some recipes/code snippets to get you started.

Essential Reading

📘

TabaPay Shield

Read here.

📘

Network Mandates

Read here.

📘

Transaction Integrity - Network Monitoring

Read here.