This topic describes the transaction resource. All payment transactions have a type, result, and status value. For information on how to inspect a payment transaction, see View payment transaction details.
type value defines the type of transaction.
|Confirms that the payment instrument is valid, that the customer is associated with the payment instrument, and that the funds are available. For payment cards, this transaction places a hold on the customer's account for the authorized amount. An authorized transaction is valid for seven days and can be captured or voided.
|Combines the authorization and capture process in one transaction. A sale can be voided prior to settlement, and can be refunded after.
|Reverses an authorization, capture, or sale transaction. A void can only occur before settlement, otherwise a refund must be used to credit the customer.
|Returns funds that had been collected from a customer's account. A refund is similar to a void, except a void must happen before the settlement of funds. On some occasions, a refund transaction can be voided.
|Permits payments to a customer's account that exceed a just refund. A credit is a special and rare type of transaction. It requires special permissions from your acquiring bank.
|Creates a payment instrument that can be used for future payments. The setup transaction performs actions from the setup instruction settings on the gateway account.
These actions are:
This process describes how to view transaction details. Select one of the following options:
View transaction details in the Rebilly UI
In the left navigation bar, click Data tables, then click Payments.
Select a segment, then in the top right of the table, click Filters .
Click Add filter.
In the first dropdown, select
In the second dropdown, select
In the third dropdown, select one or more of the following transaction types:
View declined setup transactions
To view detailed information, such as logs, on declined setup transactions:
- In the left on the screen, in the Related transactions section, click the Child transaction.
- View detailed transaction information, interact with the Transaction details, Timeline, Webhook logs, and API logs.
Click Apply filter.
In the table, in the ID column, click a transaction.
View transaction details in the Rebilly API
Using the Retrieve transactions operation, in the
type field, enter one of more of the following values separated by the
result value defines the result of completed transactions.
|When your application receives this result:
|A valid transaction is accepted by the issuing bank.
|Present the customer with a 'thank you' page which displays the billing descriptor.
|A payment transaction is not approved by the issuing bank. A reason code is supplied, which describes why the transaction is declined, such as: insufficient funds, incorrect billing address or CVV, and so on.
|Present the customer with a message stating that the transaction is declined. Ask your customer to retry the transaction with a different payment method. If you detect abuse, block the customer. For more information, see Blocklists.
|A customer began payment but did not complete it within the Time To Live (TTL) window.
|Trigger an abandoned cart outreach campaign.
|Transaction is canceled by the merchant, or by an automation, such as a blocklist match before funds are removed from their account.
|Present the customer with an option to select a different payment method.
|A transaction is in process, the status changes as it is processed.
|Check if the status is
waiting-approval. If it is, within the response, in the
_links object, locate the
approvalUrl and direct the customer to it.
To inspect a payment transaction using the UI, see View payment transaction details.
status value defines the execution status of a payment transaction.
|Transaction is created and is queued.
|Request is sent to a payment gateway.
|Transaction is completed.
|Transaction authorization, capture, or sale transaction is reversed.
|Transaction amount is partially refunded.
|Transaction amount is fully refunded.
|Transaction, or transaction amount, is disputed by the merchant or customer.
The following is a successful payment transaction status flow.
If a transaction does not receive a response from the payment gateway, or if there is a long delay in the response, one of the following statuses is returned.
|Transaction is not completed within the payment gateway account timeout period. For more information, see Set up a payment gateway - configure gateway account timeout.
|Transaction is not completed due to a connectivity issue.
|The request is not sent.
|Transaction is approved with an authorization. The funds will be captured at some point in the future.
|The transaction requires further action from the customer before it is marked as completed.
|Awaiting an approval notification from the payment gateway before the transaction is marked as completed.
|Transaction initiated. The customer has been redirected to a third-party website to complete the transaction.
- Offsite transactions: Customers must interact with a third-party website to complete a transaction. This interaction may be required as part of payment regulation.
- Instant transactions: No customer interaction is required to complete a transaction.
To prevent a duplicate transaction, generate a unique ID that and pass it to the client form. Include the ID as the
requestId property value in your transaction request. Only regenerate a different ID for the client form after you receive a
completed status in the response from Rebilly.
The payment gateway response contains a response code and message which describe the transaction. For example, if a transaction is declined, the message may contain information about why the transaction was declined. For information on how to view payment gateway response codes and messages, see View payment transaction details.
In Rebilly, the code and message received from the payment gateway is displayed in the 'Original message' and 'Original code' fields.
Rebilly uses a superset of the ISO 8583 — international standard for financial transaction card originated interchange messaging. Gateway codes are mapped to ISO 8583 as part of the gateway integration process. The standardized codes are displayed in the 'Message' and 'Code' fields. This standardized coding enables you to use the same response codes and messages across all payment gateway integrations.