Venture forth with our Backoffice Integration guide, your key to mastering operations like refunds,
reversals, captures, chargebacks, rebills, and credits. As a merchant, you’ll handle all transaction
details, ensuring a smooth experience for your team. Navigate the backoffice payment landscape with
our guide. Start today!
Initial payments via COPYandPAY or Server-to-Server allow backoffice operations.
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.
Send the reversal request to cancel the pre-authorization.
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.
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.
Send the capture request to finalize the authorized payment amount.
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.
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.
Send the refund request for returning money to the shopper.
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.
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.
As a business, it’s crucial to minimize chargebacks. Understanding how to prevent them and how to work with your
payment processing company to dispute them is key.
Send the chargeback reversal request upon dispute won by the merchant.
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.
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.
Reason:
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.
To know which acquirers or payment methods do support payment credit, please reach out to your Customer Success Manager.
Send the credit request with the collected card and bill-to data.
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.
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.
To know which acquirers or payment methods do support payment rebill, please reach out to your Customer Success Manager.
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.
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.