- Getting Started
- Tutorials
- Reference
- API Reference
- Basic Payment
- Forex
- Authentication
- Card Account
- Apple Pay
- Virtual Account
- Bank Account
- Token Account
- Customer
- Billing Address
- Merchant Billing Address
- Shipping Address
- Merchant Shipping Address
- Corporate
- Recipient
- Merchant
- Marketplace & Cart
- Airline
- Lodging
- Passenger
- Tokenization
- Recurring Migration
- 3D Secure
- Custom Parameters
- Async Payments
- Job
- Risk
- Response Parameters
- Card On File
- Chargeback
- Result Codes
- Brands Reference
- Regression Testing
- Data Retention Policy
- API Reference
- FAQ
Backoffice Operations
You can perform different types of backoffice operations using our server-to-server REST API.
- Capture an authorization
- Refund a payment
- Reverse a payment
- Receipt
- Rebill a payment
- Credit (stand-alone refund)
Note: Backoffice operations can be performed against initial payments that were generated using COPYandPAY or server-to-server. The
referencedPaymentId is the value return in the id JSON field.Capture an authorization
A capture is used to request clearing for previously authorized funds. A capture request is performed against a previous preauthorization (PA) payment by referencing its payment.id and sending a POST request over HTTPS to the /payments/{id} endpoint. Captures can be for full or partial amounts and multiple capture requests against the same PA are allowed.
Refund a payment
A refund is performed against a previous payment, referencing its payment.id by sending a POST request over HTTPS to the /payments/{id} endpoint. A refund can be performed against debit (DB) or captured preauthorization (PA->CP) payment types. Where supported, the amount field can be used to process a partial or full amount.
Reverse a payment
A reversal is performed against a previous payment, referencing its payment.id by sending a POST request over HTTPS to the /payments/{id} endpoint. A reversal should be sent against preauthorization (PA) payment type. When reversing a card payment and if sent within the time-frame the authorization is not captured yet, the reversal causes an authorization reversal request to be sent to the card issuer to clear the funds held against the authorization.
NOTE: A full reversal does not require the amount or currency to be sent. If the acquirer supports it, partial reversals are also possible. In this latter case amount and currency must be specified in the request.
Receipt
A receipt can be controlled by the customer against a previous pre-authorization payment, referencing its payment.id by sending a POST request over HTTPS to the /payments/{id} endpoint. in general, prepayment (PP) and invoice (IV) transactions trigger a credit transfer to the account of the merchant. Upon receipt of the money every incoming credit transfer from a shopper should generate a Receipt (RC) transaction which contains a reference to the prior pre-authorization. The receipt can now be triggered independently once the customer receives it from the acquiring bank.
Rebill a payment
A rebill is performed against a previous payment, referencing its payment.id by sending a POST request over HTTPS to the /payments/{id} endpoint. A rebill can be sent against a prior debit (DB payment type) transaction.
The rebill transaction payment type must be RB (paymentType=RB).
Try it out
Credit (stand-alone refund)
A credit is a independent transaction that results in a refund. The difference is that the credit is not associated with a previous transaction and so requires the full payment details to be included in the request.
Try it out