Payment types and statuses
Payment types and statuses
Understand payment states and types to implement correct business logic

An order and a transaction both relate to payments, but they have different meanings and implications.

An order is a request to purchase goods or services. It is created by a customer and is a record of what they want to buy. Orders can remain in the created state until a payment is attempted. Once a payment is attempted, the order moves to the processing state, where it stays until the payment is captured. Orders can also go through various other states, such as 3ds_verify , approved , declined , refunded , etc.

Transaction represents a particular payment associated with an order, executed by the customer. This can include created , processing , success , fail , and verify states. A transaction is created when a payment is made and moves to the processing state while the payment is being verified. If the payment is successful, the transaction moves to the success state. If the payment fails, the transaction moves to the fail state. If the payment requires 3DS verification, the transaction moves to the verify state.

Order status

p_tst_1.0

Value Final state Description
created No The order was created. It stays in this state until a payment is attempted on it.
processing No The order is in processing. An order moves to this state when a payment is first attempted on it. It remains in the state until one payment associated with that order is captured.
3ds_verify No The order goes through 3DS verification. Used in case of sending together with a parameter request for 3D or in case of making a decision to perform additional 3D verification by Solidgate or the Bank.
settle_pending No The payment has been confirmed but not yet credited to the merchant’s account. This logic applies only to Giropay/iDeal/Sofort payment methods.
approved Yes The order is approved and the payment is successful.
declined Yes The order was declined.
refunded Yes Funds by the order were transferred back to the cardholder.
auth_ok Yes Funds were successfully reserved .
auth_failed Yes Reservation of the funds is failed.
settle_ok Yes Reserved funds were successfully captured.
partial_settled Yes Part of the funds was successfully captured.
void_ok Yes Operation of fund reservation was voided.
The final state means the one in which the order can remain until the subsequent operations (settle, void, refund) and this is a reasonable logic of system processing.

Transaction status

Value Description
created The transaction was created.
processing The transaction is currently undergoing processing.
verify The transaction is going through 3DS verification. Redirect the customer to the ACS URL provided in response to finalize the payment.
settle_pending The payment has been confirmed but not yet credited to the merchant’s account. This logic applies only to Giropay/iDeal/Sofort payment methods.
fail The transaction has been rejected. Refer to the decline code for additional information.
success The transaction has been successfully proccessed.

Transaction type

Value Description
pay The operation of charging, which includes authorization and capture in a single transaction.
recurring The operation of executing payments using a token for repeated transactions.
recurring-auth The operation of reserving funds using a token.
refund The operation of transferring funds back to the cardholder.
resign The operation of executing payments using a token in conjunction with the CVV.
resign-auth The operation of reserving funds using a token and CVV.
auth The operation of reserving funds.
settle The operation of settling reserved funds.
void The operation of cancelling a reserved fund.
apple-pay The charge via Apple Pay.
google-pay The charge via Google Pay.

Related articles FAQ

Order lifecycle
How to switch from one-step to two-step payment flow?
Frictionless flow
Protection from double charge