Card Payments

A card payment is a payment made from a payer to a payee through a card network. A card network connects the payer’s bank, the issuer, and the payee’s bank, the acquirers, in order to provide payments between the payer and the payee. Card payments are enabled through account access mechanisms called cards that contain all of the details necessary for a payee to request payment from the payer.

Card Purchase

A purchase is when a consumer pays a merchant in exchange for goods or services. Purchases can be done in person or online. Card payments allow merchants to process a purchase securely and in real time regardless of the bank of the consumer. Card payments also allow for easier processing and reconciliation than cash, checks, or ACH.

Card Withdrawl

A cash withdrawal is when an end user receives cash from an automated teller machine (ATM) in return for having funds withdrawn from their bank account. In this case, the ATM acts similar to a merchant and the consumer is essentially paying the ATM operator in return for receiving cash. Cash withdrawals are processed using a single request.

Actions

Authorizations

When an authorization request is received, Build performs a series of checks on the account including:

Velocity limits Merchant controls PIN validation Card blocks Account blocks Callback response from our customer If the authorization request passes all of these checks, then an authorization hold is generated for the account and a success response is returned to the card network.

Incremental authorization

When an incremental authorization request is received, Build performs the same checks as with a new authorization, but only for the incremental amount. If the incremental authorization request passes all of the checks, then the original authorization hold is released, a new authorization hold for the updated amount is generated, and a success response is returned to the card network.

Please note that for a sequence of incremental authorizations, the original_auth_id field should contain the ID of the first authorization. Additionally, all clearings related to these incremental authorizations should have the ID of the first authorization in the authorization_id field.

Reversal

When a reversal request is received, Build will locate the original authorization hold on the account and release it, thus making the funds available to the end user again.

Reversals are linked through the original_authorization_id or original_transaction_id field to original authorizations/transactions. When the call is made to your system, the following actions are expected to be executed:

• If full reversal: Release authorization hold from the account
• If partial reversal: Release of the original authorization hold from the account and generation of an updated authorization hold

In the request body, reversals will include either the authorization_id field (when authorization is reversed) or the original_tx_id field (when a clearing is reversed).

Refund

When a refund request is received, Build will credit the account for the refund amount. Refunds can be for the full amount of the purchase or for a partial amount. The refund transaction will not be associated with the original purchase transaction.

Clearing

When a clearing request is received, Build will locate the original authorization hold related to a purchase, release the authorization hold, and then debit the account for the final purchase amount.