Transactions have a status, result, and type.
Here is the typical status flow for a transaction:
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:
A typical result flow for a transaction:
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.
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.
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.
To troubleshoot further, you may wish to see your own applications requests related to the transaction. View the related API logs.
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.
Both the standardized response code and the original are helpful when investigating a transaction.
Reconcile any discrepancy between the amount/currency and/or result logged in Rebilly and the downstream payment gateway by selecting Query gateway.
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.
had discrepancy and
is reconciled filters in the data tables.
Use webhooks to stay updated about any discrepancies. Subscribe to these webhooks: