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

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 API: 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 API 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 API.

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.

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

• 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 and 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.

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