Most transaction requests follow the lifecycle described below, with some potential variations. For developers building in-person or ecommerce integrations, understanding this lifecycle can help when integrating payment API request calls and receiving responses. Since there are multiple stops along the request path, there are also multiple potential points of failure to be aware of when creating the application design and troubleshooting errors.

1. Credit card data is obtained from a physical or online Point of Sale (POS) system and formatted for the request.
   • The customer’s mobile wallet, credit or debit card data is accepted using whichever payment method the merchant’s environment is set up for.

     • For ecommerce payment integrations, the data is typically keyed into a web form.
     • For card-present integrations, the card is physically read using payment hardware, like a PAX or Ingenico terminal or a mobile credit card reader.
   • After reading the card data, most payment software running on physical terminals will format the request so it can be sent via the payment processing API.
   • Some transaction requests may use a tokenized version of the card data that was returned from the initial card-intake transaction. For example, customers may enter their card data on a hosted payment page, which returns a secure, tokenized version of that data that merchants can store and use for subsequent transactions without needing to meet additional Payment Card Industry (PCI) requirements.
2. Request is processed
   • Payment Gateway and Processor: If the merchant or Independent Software Vendor (ISV) who built the software for the merchant is using a payment gateway, the request is routed first to the gateway, then to the processor.
   • No Gateway, Payment Processor only: If the merchant isn’t using a gateway, the request is routed directly to the payment processor.
3. Processor routes the request to the credit card network
   • If the processor approves the request, they route it to the card network associated with the card data in the request, such as Mastercard or Visa.
4. Network routes the request to the card-issuing bank
   • If the card network approves the request, they route it to the last destination on the route: the bank that will be issuing the funds.
   • If the issuing bank approves the request, an approval response is returned along the same path.
   • Otherwise, a failure response is returned, which provides information about the error. Most payment failures are called "Declines" especially if they happen at the last step: the issuer bank. The failure responses that a financial institution or credit card network can return are generally standardized within the payment industry.
5. Request is complete
   • Once the response reaches the resource that initiated the request, the request is complete.

At each stop along the request route, validation checks are performed to ensure the request meets that organization’s criteria. For example, the payment processor runs the request data against a series of fraud detection rules before forwarding it to the next stop. If any group involved in the process does not approve the request, it is automatically declined and a failure response is returned.

Transferring funds from one bank account to another involves a series of transactions. Each transaction accomplishes a specific task using a specialized credit card processing API endpoint. In general the funding process includes the following steps.

1. Transactions are authorized and captured, which adds them to the merchant’s batch of transactions.
2. The “Batch Close” endpoint is called through the merchant's automated or manual processes, which initiates the funding process. The batch data is forwarded to the processor or gateway. If the merchant is using a payment gateway, the request is routed first to the gateway, then to the processor. If the merchant isn’t using a gateway API, and is instead using a direct payment integration, the request is routed directly to the processor.
3. If the processor approves the request, it is sent on to the card networks. The processor will group the payment transaction data in multiple batch lists based on card types, and then submit a separate batch list to the appropriate card brand. (For example, the processor submits all Mastercard transactions to Mastercard, and American Express transactions to American Express.)
4. If the card networks approve the requests, they are sent to the cardholders’ banks.
5. The banks validate the requests.
6. If the banks approve the requests, they disburse the funds to the card networks.
7. The card networks disburse the funds to the processor’s account.
8. The processor disburses the funds to the merchant’s or customer’s bank account (depending on whether the transfer was for a Sale or Refund), less any fees agreed upon in the merchant-processor contract.

Merchants may wish to transfer funds between bank accounts for various reasons, such as making a Sale or a Refund. Payment API endpoints that are designed to handle specific transaction types can be used to accomplish these tasks. Some of the most common transaction types include the following.

• Batch Close: This transaction type initiates the funding process.
• Refund: This transaction type obtains approval from the merchant’s bank to transfer funds to the customer’s account, and immediately places the transaction into a batch. This can be done before or after Batch Close.
• The following transaction types can only take place prior to Batch Close:

  • Authorization: Requests bank approval to transfer funds. The issuing bank will withhold the funds for every approved authorization until it is either captured and funded or reversed. If no subsequent action is performed after authorization, the funds are released after a number of days (typically 3 - 7 days).
  • Capture: Edits and/or finalizes the amount of an authorized transaction. The Capture transaction type places the transaction into a batch, marking it ready for settlement.
  • Sale: Obtains approval from the customer’s bank to transfer funds to the merchant’s account, and immediately places the transaction into a batch. The Sale endpoint of North’s Browser Post API is one example of this transaction type.
  • Verify (Address Verification Service only): Tokenizes card data without charging the card and can be used to verify the billing address as an extra security measure.
  • Void: This transaction type works differently depending on the transaction that is being voided. Voiding an Authorization releases the allocated funds from the issuing bank during settlement. Voided Captures are simply canceled and removed from the batch list — they are only sent to the processor, and are not forwarded to the card network or bank.
  • Reversal: This transaction type can only be used with Authorizations that haven’t been captured yet or Sales that haven’t been settled. It removes the authorization hold and voids the transaction in the same request, releasing the allocated funds from the issuing bank.

Payment integrations that offer most or all of the transaction types listed above are considered full-featured. For example, North’s Custom Pay API offers endpoints for Authorization, Capture, Sale, Refund, Void, and more. Some integrations only offer a limited set of transaction types, such as Sale and Refund. The feature set that’s right for a business depends on their unique needs.

For example, a common use case for sending separate Authorization and Capture transaction requests is to accept tips. Sending separate requests allows businesses to authorize the amount of the bill at the time the customer checks out, then edit the authorized amount to add the tip in the Capture request so the full amount is funded.

The transaction lifecycle and funding processes are highly complex, but for developers building payment integrations, the most important takeaways are relatively simple. In order for transactions to be approved, the request data must be valid. Ensuring that the data is compiled correctly is the first step — and arguably the most important one. Next, responses must provide end users with the information needed to understand where errors originate from in the event that there is a problem with a request. Transaction response codes are standardized within the payment industry, so this generally means that the payment app simply displays the response code that was forwarded from the processor.