Transactions have a status, result, and type.

transaction details


Here is the typical status flow for a transaction:

a request is sent to a gateway
a response is returned from the gateway
Transaction Created

Some transactions do not receive a response, or will receive a response some time in the future. In those cases, the transaction will have one of the following responses:

  • Timeout - the transaction was not completed within the allotted amount of time. The timeout window is configurable in the gateway account settings.
  • Conn-err - the transaction was not completed due to a connectivity issue.
  • Never-sent - the request was not sent.
  • Waiting-capture - the transaction is approved with an authorization and the funds will be captured some time in the future.
  • Waiting-approval - the customer must take some further action before the transaction can be marked as completed.
  • Waiting-gateway - the gateway needs to send a notification of approval before the transaction can be completed.
  • Offsite - the transaction was initiated and the customer has been directed to a 3rd party website to complete the transaction.

A completed transaction may have another action taken, which would update the status once again:

partial refund issued
full refund issued
full refund issued before funds are removed from the customer's account
a dispute is logged
Partially refunded


A typical result flow for a transaction:

request sent to the gateway
approved response received
declined response received
Transaction initiated

An incomplete transaction will have one of the following statuses:

  • Abandoned - the customer did not complete the transaction within the TTL window. The TTL window is configurable in the gateway account settings.
  • Canceled - the customer explicitly canceled the transaction.

The transaction timeline shows more details about the response.

declined reason


A transaction will be one of the following types:

  • 3ds-authentication - a 3ds authentication transaction is an authentication using 3D Secure of the payment card. The amount can be for $0. This transaction type is typically used when a customer is adding a card on file to be used at a later time.
  • Authorize - an authorization places a hold on the funds in a customer's account. The funds may or may not be captured on a later date. An authorization is typically valid for seven days.
  • Capture - a capture collects all or some of the funds that had been previously authorized in a customer's account.
  • Credit - a credit transaction adds funds to a customer's account.
  • Refund - returns funds that had been previously collected from a customer's account.
  • Sale - collects funds from a customer's account.
  • Setup - performs actions from a gateway account's settings, on a provided payment instrument, to prepare the instrument for later payments. This can be authorize, authorizing and voiding, strong customer authentication (SCA) or do nothing.
  • Void - if a refund is issued before the funds were collected from the customer's account, the initial transaction is voided.

Communication logs

When troubleshooting a transaction with a 3rd party gateway provider, they will need to see the communication logs in order to investigate. Use the copy icon next to the timestamp to copy the communication logs.

Note: Only the PAN, CVV, and secret authentication keys are redacted.

copy response from timeline

To troubleshoot further, you may wish to see your own applications requests related to the transaction. View the related API logs.

view related API logs

click to expand

Response codes and messages

The response from the gateway contains a response code that correlates to a response message. The code and message contains information about whether the transaction was approved or declined. If the transaction was declined, the message may contain additional information about why the transaction was declined.

We store the code and message received from the gateway as the original code and message.

Rebilly uses a superset of the ISO 8583 (the international standard for financial transaction card originated interchange messaging). We map the gateway's code to the ISO 8583 as part of our integration process. The standardized codes are stored as the response code and message in Rebilly. The standardized coding allows you to use the same response codes and messages across all of your gateway integrations.

response example

Both the standardized response code and the original are helpful when investigating a transaction.

Query transaction

Reconcile any discrepancy between the amount/currency and/or result logged in Rebilly and the downstream payment gateway by selecting Query gateway.

query gateway button

If no discrepancy is found, you will see a note that your transaction is up-to-date.

If a discrepancy is found, you have the opportunity to update the transaction. After the transaction is updated, it will be considered reconciled. The discrepancy and reconciliation will be logged in the transaction timeline.

discrepancy timeline message

Use the had discrepancy and is reconciled filters in the data tables.

had discrepancy in data tables

Use webhooks to stay updated about any discrepancies. Subscribe to these webhooks: