Transactions

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

The type value defines the type of transaction.

Type	Description
`authorize`	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.
`sale`	Combines the authorization and capture process in one transaction. A sale can be voided prior to settlement, and can be refunded after.
`void`	Reverses an authorization, capture, or sale transaction. A void can only occur before settlement, otherwise a refund must be used to credit the customer.
`refund`	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.
`credit`	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.
`setup`	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: `do nothing`: A `setup` transaction is created and automatically marked as approved. The payment instrument is created and no further validation takes place. `authorize`: Creates a `setup` transaction with an associated `authorization` child transaction. The result of the `setup` transaction matches the result of the `authorization` transaction. The `authorization` amount is equal to the `setup` transaction amount. For example, if `0` is sent as the amount, a `0` `authorization` is executed. `authorize and void`: Creates a `setup` transaction with an associated `authorization` child transaction. The result of the `setup` transaction matches the result of the `authorization` transaction. If approved, the `authorization` transaction is immediately voided. If the setup transaction amount is $0, a $1 authorization is created; otherwise, the setup transaction amount is used. `Strong Customer Authentication (SCA)`: Creates two transactions, a `setup` transaction and a `3ds-authentication` child transaction, which validates the cardholder by instructing them to authenticate their card through their issuing bank. This process is called 3D Secure (3DS) and may require the cardholder's interaction. For more information, see 3D Secure.

View transaction details

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, press Data tables, then press Payments.
Select a segment, then in the top right of the table, press Filters .
Press Add filter.
In the Filter dropdown, select Type.
In the Operation dropdown, select is in.
In the Value field, select one or more of the following transaction types:
- authorize
- sale
- void
- refund
- credit
- 3ds-authentication
- setup
View declined setup transactions
To view detailed information, such as logs, on declined setup transactions:
1. In the right on the screen, in the Related transactions section, press the Child transaction.
2. View detailed transaction information, interact with the Transaction details, Timeline, Webhook logs, and API logs.
Press Apply filter.
In the table, in the ID column, press 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 ; character:

authorize
sale
void
refund
credit
3ds-authentication
setup

Example: type=setup;3ds-authentication.

Result

The result value defines the result of completed transactions.

Result	Description	When your application receives this result:
`approved`	A valid transaction is accepted by the issuing bank.	Present the customer with a 'thank you' page which displays the billing descriptor.
`declined`	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.
`abandoned`	A customer began payment but did not complete it within the Time To Live (TTL) window.	Trigger an abandoned cart outreach campaign.
`canceled`	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.
`unknown`	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

The status value defines the execution status of a payment transaction.

Status	Description
`pending`	Transaction is created and is queued.
`sending`	Request is sent to a payment gateway.
`completed`	Transaction is completed.
`voided`	Transaction authorization, capture, or sale transaction is reversed.
`partially-refunded`	Transaction amount is partially refunded.
`refunded`	Transaction amount is fully refunded.
`disputed`	Transaction, or transaction amount, is disputed by the merchant or customer.

Successful payment transaction flow

The following is a successful payment transaction status flow.

Error and additional processing status

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.

Status	Description
`timeout`	Transaction is not completed within the payment gateway account timeout period. For more information, see Set up a payment gateway - configure gateway account timeout.
`conn-error`	Transaction is not completed due to a connectivity issue.
`never-sent`	The request is not sent.
`waiting-capture`	Transaction is approved with an authorization. The funds will be captured at some point in the future.
`waiting-approval`	The transaction requires further action from the customer before it is marked as completed.
`waiting-gateway`	Awaiting an approval notification from the payment gateway before the transaction is marked as completed.
`offsite`	Transaction initiated. The customer has been redirected to a third-party website to complete the transaction.

Offsite and instant transactions

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.

Prevent duplicate transactions

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.

Payment gateway response codes and messages

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.

Our Solutions

Products

Features

Solutions

About