Backoffice Integration Guide

Reversal

The merchant voids the entire open amount of a pre-authorization. Depending on the payment method, the pre-authorization expires usually after a couple of days unless it is already captured or cancelled.

Here are the main reasons for cancelling a pre-authorized payment before it is settled:

• Duplicate transactions: Errors in payment or delivery information, or delays in finalizing the purchase.
• Customer change of mind: The customer decides to cancel the transaction.
• Product unavailability: The purchased product or service becomes unavailable.

---

How it works

Transactions:

---

1. Pre-authorize payment

Initiate a server-to-server POST request with the required payment data. The payment details are verified with the issuer, and the funds are reserved. The response to a successful request is an id that should be stored and used in reversing the pre-authorization.

2. Reverse the payment

Initiate a server-to-server POST request over the pre-authorized payment. The payment is cancelled when you have authorized a payment but do not want to capture it, for example because an item is out of stock. The reserved funds are released to the shopper's account.

Sample request:

Capture

The merchant captures the full or partial amount of an authorized payment for settlement.

Here are the main reasons for capturing a transaction after it has been pre-authorized:

• Product availability: The product or service that the customer ordered is available and ready for delivery.
• Order fulfillment: The order has been prepared and is ready to be shipped or provided to the customer.
• Customer confirmation: The customer has confirmed their order details and agreed to the terms of the sale.
• Fraud checks: All necessary fraud checks have been completed and the transaction is deemed legitimate.

---

How it works

Transactions:

---

1. Pre-authorize payment

Initiate a server-to-server POST request with the required payment data. The payment details are verified with the issuer, and the funds are moved. The response to a successful request is an id that should be stored and used in capturing the full or partial amount.

2. Capture the payment

Initiate a server-to-server POST request over the authorized payment which is the original transaction that needs to be captured. The authorized amount is finalized and money is transferred from the shopper to the merchant. The capture process typically occurs immediately after the authorization, but can vary depending on the payment method.

Sample request:

Refund

The merchant refunds the full captured amount or a part of the captured amount.

Here are the main reasons for refunding a transaction after it has been settled:

• Unmet expectations: The product or service did not meet the customer’s expectations.
• Damaged or defective products: The product received by the customer was damaged or defective.
• Incorrect product: The product wasn’t what the customer expected due to bad descriptions or shady selling.
• Incorrect amount charged: The wrong amount was charged.
• Duplicate transaction: The transaction was duplicate.
• Product unavailability: The item ended up being sold out.
• Change of mind: The customer changed their mind after ordering.

---

How it works

Transactions:

---

1. Perform debit payment

Initiate a server-to-server POST request with the required payment data. The payment details are verified with the issuer, and the funds are moved. The response to a successful request is an id that should be stored and used in refunding the full or partial captured amount.

2. Refund the payment

Initiate a server-to-server POST request over the debit payment which is the original transaction that needs to be refunded. The original charge is reversed and money are sent back to the shopper. The refund issuance period varies by the payment method, but typically ranges from a few days to up to a year after the original transaction.

Remember, when issuing a refund, it’s crucial to communicate with the shopper about the process and expected timeline for the refund to appear in their account. This helps maintain good customer relations and trust.

Sample request:

Chargeback

The merchant reflects the chargeback and its reason as received from the bank to indicate a reversal of funds from the merchant's account into the shopper's account. This typically happens when a shopper disputes a debit or credit card charge with their bank, leading to a reimbursement, rather than dealing directly with the business that made the charge.

Originally, chargebacks were designed as a form of consumer protection against credit card fraud. However, they can also be initiated due to billing errors, unresolved customer complaints, or unrecognized charges.

---

How it works

Transactions:

---

1. Perform debit payment

Initiate a server-to-server POST request with the required payment data. The payment details are verified with the issuer, and the funds are captured. The response to a successful request is an id that should be stored and used in chargeback to reflect the reversing of the funds.

2. Perform the chargeback

Initiate a server-to-server POST request using the post-payment authorization id. A chargeback signifies the reversal of funds back to the shopper’s account following a dispute. When a shopper initiates a chargeback, the merchant is entitled to contest the legitimacy of the original transaction. The merchant can do this by collecting and presenting persuasive evidence (such as receipts, delivery confirmations, etc.) that contradicts the shopper’s claim. This procedure of challenging a chargeback is referred to as representment.

Sample request:

3. Perform the chargeback reversal

Initiate a server-to-server POST request using the chargeback payment id to perform a chargeback reversal. This reversal takes place subsequent to the representment process. If the issuing bank rules in favor of the merchant after reviewing the provided evidence, the chargeback is then reversed. Consequently, the funds initially debited from the merchant and credited to the shopper due to the chargeback are retracted from the shopper and reinstated to the merchant. Notably, even in the event of a chargeback reversal, the merchant remains liable for the chargeback fee, and the transaction continues to contribute to the merchant’s chargeback ratio.

In summary, representment is the procedure of contesting a chargeback, and a chargeback reversal is a potential result of this dispute.

Sample request:

Payout

The merchant uses standalone credit transactions, also known as a standalone refunds, to transfer funds from their account back to the shopper’s account without a corresponding debit transaction. This could occur in several scenarios:

• Expired Refund Window: When the standard timeframe for refunds, usually 60 days, has passed but you still need to return funds to the shopper. For example, if a shopper returns a product after 70 days, you would initiate a standalone credit transaction.
• Billing Error Correction: When a billing error has occurred and you need to correct it. For example, if a shopper was accidentally billed twice for a single item, you would issue a standalone credit for the amount of the duplicate charge.
• Customer Service Gesture: When you want to provide a credit as a gesture of good customer service. For example, if a shopper had a poor experience, you might issue a credit as an apology and a way to maintain a positive relationship.

Unlike regular refunds, a standalone credit has no relationship to any original capture of funds. To issue a refund via standalone credit, the merchant must obtain the cardholder’s card and bill-to information. This ensures fairness in transactions and maintains shopper satisfaction.

---

How it works

Transactions:

---

1. Payout shopper

Initiate a server-to-server POST request with the collected card, payment and billing data. The payment details are verified with the issuer, and the funds are credited to the shopper's account. The response to a successful request is an id that should be stored and used later in refunding the credited amount if required.

Rebill

Payment rebill means charging a shopper the right amount for something they bought from you. You may need to do this in three cases:

• Estimated and incremental authorizations: This occurs when the final sale price differs from the estimated price at the time of purchase. For instance, if you’re selling a service like a taxi ride or a hotel room, the exact amount may not be known until the service is fully rendered.
• Incorrect refund: This happens when you refund a shopper an amount greater than what they paid. For example, if a product sold for $10 is mistakenly refunded for $20.
• Incorrect chargeback: This arises when a shopper files for a chargeback (a request for a refund) but isn’t entitled to it. For instance, if they assert that they didn’t receive the product or service, but you possess evidence to the contrary.

Rebill payments help prevent shopper confusion and financial loss on your part.

As for why to use a rebill instead of a chargeback reversal, it’s important to note that these two processes serve different purposes. A chargeback reversal is used when a merchant disputes a chargeback and the issuing bank rules in their favor, returning the funds to the merchant. On the other hand, a rebill is used when a merchant needs to charge a customer again, often due to the reasons mentioned above.

---

How it works

Transactions:

---

1. Perform debit payment

Initiate a server-to-server POST request with the required payment data. The payment details are verified with the issuer, and the funds are captured. The response to a successful request is an id that should be stored and used in subsequent backoffice operations.

2. Rebill the authorized payment

Initiate a server-to-server POST request using the id of a successfully authorized payment. In this scenario, the merchant may incorporate additional charges that were not part of the original authorization. This could be due to extra services or products purchased.

It’s important to note that the amount of a rebill transaction is indeed on top of the initially authorized and captured amount. This means that if the original transaction was for $100, and there’s an additional charge of $20, the total amount charged to the customer would be $120. The rebill transaction allows the merchant to capture the additional $20 without requiring a new authorization from the customer.

Sample request: