API reference
Coming soonUnderstand payment statuses, refunds, disputes and payouts for your existing merchant integration.
Etail APIs and tools are not available yet. This guidance is for existing merchant connections.
On this page
Payment status
Check authorization, capture and uncertain results before fulfilling an order or starting another payment.
Before you begin
- Access to the merchant account that received the payment
- The order and transaction references, if available
- The amount, currency and transaction time with its time zone
Find the original payment
- PurchaseYour orderAmount, currency and attempt references
- ProcessingPayment and related operationsAuthorization, capture, reversal and refund references
- ReportingAccount activity and payoutSettlement, adjustments and deposit references
Start with the returned transaction ID
Search the merchant account and environment used for the payment. If no transaction ID was returned, use the original order or merchant reference and a narrow time range.
Match the purchase
Match the merchant, amount and currency. Retain the separate identifiers for the order, authorization, capture, reversal and refund.
Open the related activity
Read the linked operations before acting. A capture and refund on one order are separate operations, not separate purchases.
Read the status before taking action
Read the recorded operation as well as its status. Use these distinctions alongside the status definitions provided for your integration.
| Observed state | Meaning and next check |
|---|---|
| Authorized | An authorization was approved. Check the configured capture and fulfillment policy. An authorization is not a bank deposit. |
| Capture accepted | A capture has entered processing. Follow its result and settlement; do not capture again because the payout has not arrived. |
| Declined | The recorded attempt was not approved. Follow the returned reason and permitted retry rules. If there was an earlier uncertain attempt, resolve it separately. |
| Pending or unknown | The outcome is not yet established. Keep the order under investigation and recover the original attempt before taking another payment action. |
| Voided or refunded | Check whether the void or refund completed. An accepted refund request and the customer’s bank posting are different events. |
| ACH submitted | A bank payment instruction was submitted. Follow its own completion and return states; card authorization/capture labels do not describe the ACH lifecycle. |
Resolve an uncertain result
Preserve the original attempt
Keep the original order, merchant, amount, time and any returned transaction or correlation reference. Tell the customer the result is being checked rather than declaring an unverified failure.
Check the payment record
Use the account’s payment lookup or ask merchant support to trace the original attempt. Compare related operations and verified notifications. A communication error does not show how far processing progressed.
Record the resolution
Update the order from the confirmed result. If it remains unclear, assign someone to follow up and retain the unresolved attempt instead of submitting a new charge.
Two transactions have the same amount
Compare the operation types, references and the orders they belong to. Two similar rows can be different purchases, separate operations or duplicate attempts; the amount alone does not decide.
The checkout message and account record disagree
Retain both references and the time observed. Resolve the current processing record before changing fulfillment or sending the customer through another payment.
For integrations: interpret a lookup result
Use the payment lookup specified for your integration to monitor status. Follow its rate limits and recovery rules; repeatedly running broad transaction searches is not a substitute for a defined recovery process.
| Result to interpret | Next check |
|---|---|
| Empty lookup | Confirm the identifiers, account scope and reporting availability. An empty result is not a payment decline. |
| Request accepted | Determine whether the requested action completed or remains pending. Trace the original operation before retrying. |
| Payment update received | Verify its source, account and operation before applying it. A repeated notification must not repeat a business action. |
Keep the details needed for investigation
- Account and purchase
- Merchant account, environment, order and original attempt references.
- Payment and operation
- Available transaction and operation references, amount, currency and time zone.
- Investigation
- What happened, what you expected, who is following up and the next step. Remove sensitive information before sharing error details with support.
Refunds and disputes
Start with the original payment, choose the appropriate action and follow the refund or dispute to its outcome.
Before you begin
- The original payment and related operation references
- Permission for the action you need to take
- The customer request, remaining refundable amount and any open dispute
Choose the action for the payment stage
| Current position | Action to check |
|---|---|
| Open authorization | Check whether an authorization reversal is supported for the current authorization. A reversal and a refund have different purposes. |
| Capture or credit awaiting processing | Check whether a void remains available for that operation. Eligibility depends on its current processing stage and your integration. |
| Captured payment | Check whether a linked refund is permitted. Use the capture or sale reference and the remaining refundable amount. |
| Open dispute | Read the case instructions and check earlier refunds before issuing a refund. Coordinate the response so the customer is not credited twice. |
A void is no longer available
Recheck the current operation and which actions are allowed next. Do not repeatedly submit a void after processing has moved beyond the eligible stage.
A hold remains after a void
Voiding a capture does not necessarily release the authorization hold. Check whether a separate authorization reversal is required and supported before describing the funds as released.
Track a refund through its result
Review the payment and case history
Confirm the original capture or sale, currency, earlier refunds, unresolved requests and any dispute. Confirm which purchase and amount are being refunded.
Check the amount still available
Check the account’s confirmed refundable amount and limits. Include completed refunds and pending, uncertain or reserved amounts so the same remainder cannot be used twice.
Submit one permitted action
Use the linked payment reference and authorized account access. Keep the returned refund or operation ID, requested amount and submission time.
Confirm and communicate the result
Record whether the refund completed, failed or remains pending. If the response is lost, investigate that operation before repeating it. Give the customer the verified status and only the posting timeframe confirmed for the account.
For platforms handling concurrent refunds
Reserve pending amounts atomically before submission so concurrent requests cannot use the same remainder. Resolve uncertain outcomes before releasing a reservation. This is an application safeguard, not a balance held by the payment service. Investigate a negative remainder instead of setting it to zero.
A refund is still pending
Keep its original reference. Check the original processing record or contact support. A successful submission response does not by itself establish final completion or customer receipt.
Respond to the dispute notice
- Read the case notice
Match the case to its payment. Record the reason, stage, deadline and time zone, and the action requested.
- Review the purchase and prior credits
Check the order, delivery or access records, customer communications and earlier refunds. Respond according to the case instructions.
- Submit the relevant response
Address the stated reason in the required format. Confirm submission and retain its acknowledgment; an uploaded or saved file is not proof of submission.
- Follow the case to its outcome
Track further requests, the decision and each account adjustment. Keep later debits and credits connected to the case and reporting period.
The purchase has already been refunded
Retain the refund reference, amount and confirmed result with the case. Follow the notice and support instructions before issuing any further credit.
The response receipt is missing
Check the record of the response submitted for the case or contact the case team before the deadline. Follow up until submission is confirmed or you know the next action required.
Match refunds and disputes to account adjustments
| Record | What to check |
|---|---|
| Refund | Match its operation reference, amount and result to the original payment and the report where it is deducted. |
| Dispute debit or credit | Keep the case reference with each financial adjustment. A case decision and its accounting entry may arrive separately. |
| Funding period | Check which payout includes the adjustment. A later refund or case adjustment may affect a different payout from the original sale. |
Payouts and reconciliation
Match payments, fees and adjustments to the payout report, then confirm the deposit on your bank statement.
Before you begin
- Merchant transaction and funding report access
- The account’s payout terms, cutoff and reporting time zone
- The receiving bank’s statement or posted transaction record
Follow the payment to bank deposit
- Capture
Keep the accepted capture or sale reference with the original order. Authorization alone is not an amount received by the business.
- Settlement
Identify the processed activity included in the relevant settlement or funding report. Do not assume every capture appears in the next payout.
- Payout calculation
Read the included activity and the report’s fees, refunds, dispute adjustments, reserves and credits. Check whether charges are netted or billed separately.
- Bank deposit
Match the final funding amount, currency and reference to the bank’s posted entry. Keep any unmatched difference open for investigation.
Reconcile the payout amount
Select the merchant deposit
Confirm the merchant, currency, deposit reference, period and expected destination. A batch for the platform can contain several merchant deposits.
Match its included activity
Use the payments and adjustments listed in that report. Preserve their references and recorded signs, including corrections relating to earlier periods.
Calculate the amount once
Separate netted deductions, credits and amounts held. Do not subtract a fee again if it is already included in a net total, or deduct a separately billed fee from this deposit.
Match the bank entry
Compare the reported funding amount with the posted bank credit and reference. Record the match, or record the difference and who will follow up.
Read batch and deposit results separately
A funding batch and an individual merchant deposit can have different outcomes. Match the record and merchant before applying its reported status.
| Record | What to check |
|---|---|
| Funding batch | The outcome of the group of deposits. A partial rejection does not mean every merchant deposit failed. |
| Merchant deposit | The outcome and any rejection or return affecting that merchant’s deposit. |
| Bank entry | The posted amount and reference that establish receipt in the bank account. |
For integrations: match the batch and merchant
Keep the batch reference, each merchant deposit reference and the account mapping together. Do not apply a batch result to every merchant without checking its deposit.
A funded notification arrives again
Record delivery separately from the funding result. A repeated event is not a second bank deposit and must not duplicate a reconciliation entry.
Investigate a missing or different deposit
- References
- Merchant, individual deposit, any funding batch and the report period.
- Difference
- Reported amount and currency, bank amount and reference, observed status and any later adjustment.
- Next action
- The unmatched amount, who is following up and the next step. Use a masked destination reference when contacting support.
The payout is less than the sales total
Compare the included period, cutoff and time zone first. Then account for refunds, fees, disputes, reserves, credits and separately billed charges. Do not subtract a deduction twice.
The report says funded but no bank credit appears
Check the current merchant deposit status, expected timing under the account terms, receiving account and any rejection or return. Ask support to trace the existing deposit when the expected timing has passed.
Only part of a batch was rejected
Inspect the individual merchant deposits and their causes. Reconcile successful deposits separately and leave the rejected or unresolved items open.
The bank entry is different or was returned
Keep the bank reference, amount, date and currency with the original deposit. Check for later adjustments or returns and ask merchant support to investigate any amount you cannot match.
For integrations: funding instructions
Only submit funding instructions when your account permits it. Reporting access does not grant this permission. Request the supported operations and recovery procedure from our integration team; track each instruction separately from its funding result.
| Record | What it establishes |
|---|---|
| Instruction | A request for a permitted funding action and its submission outcome. |
| Funding result | The later processing result for the relevant batch or merchant deposit. |
| Bank record | The posted receipt or return in the receiving account. |