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 make a payment to pay off the balance of their credit card, or funds sent to them as credit.

👍

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

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.

Why Debt Repayment?

• Faster Funding: Use card payments to receive guaranteed payments within in 24–48 hours, vs. five days for checks processing.
• Lower Costs: Reduce operational overhead and eliminate returned checks.
• Customer Preference: Consumer borrowers increasingly prefer debit card payments over checks, or ACH.
• Operational Efficiency: Reduce late payments and improve cash flow with automated recurring transactions.
• Guaranteed Funds: Reduce risk of NSF compared to checks.
• Improved Cash Flow: Payments are processed and available quickly, even for large amounts.

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.

Including Partial Authorization

3. Set Partial Authorization Flag: Set the partial field in pullOptions to true to indicate that partial authorization is requested.

...   
"pullOptions": {
        "recurringData": {
            "initial": true,
            "initiator": "C",
            "type": "R"
        },
        "partial": true
    },
    "ref
...

Note: For a full request, refer to Partial Auth Pull Transaction.

4. Handle Create Transaction Response: If the Create Transaction API response includes the partialAmount field, and PARTIAL_COMPLETED status, it indicates that the transaction was partially authorized.

{
  "SC": 200,
  "EC": "0",
  "transactionID": "TabaPay_TransactionID_",
  "network": "Visa",
  "networkID": "123454646545645",
  "networkRC": "00",
  "partialAmount": "0.01",
  "status": "PARTIAL_COMPLETED",
  "approvalCode": "000000"
}

Provide Receipt and Cancellation Confirmation:

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

Recipes

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

More Resources

• Overview of TabaPay Shield: Include features to protect your platform and customers against fraud.
• Network Mandates: Follow the most recent updates and requirements by card networks.
• Transaction Integrity - Network Fees: Follow best practices recommended by card networks.