Transaction State Transitions

Overview

Concardis Payengine comes with an order and state transition concept that allows you as merchant and/or integrator to get information on the current state of a payment, i.e. if funds have been transferred or if a customer got declined by a processor etc.

Based on the dedicated status that is always returned through our API, you may take appropriate actions, such as shipping the goods, contact the customer for clarification or similar.

It's worth mentioning that "listening" to the Payengine order and transaction state changes is enough to deal with any possible business case that may arise with any supported payment method- you don't need to translate each payment method's individual states. This job is done by Concardis Payengine, offering you a sole source of aggregated payment status information.

This following section allows you to understand (also in the context of a certain payment method that was used by the customer)

• a) what each status means

• b) when a certain status occurs

• c) what a possible following status could be

State Transitions: Order

Payengine payment transactions always need a parenting entity: the order. An order carries all required information to perform multiple types of transactions, that is a customer, a persona, shipping & billing addresses and payment information. Before you can debit a payment instrument (e.g. a credit card of your customer), you need to create an order. Therefore, the initial status of an order is CREATED. During the 'lifetime' of an order, it remains OPEN but as soon as no further action can follow, it will change to CLOSED.

State Transitions: debit & capture

Transaction types debit and capture are both booking a certain amount on the customers payment instrument, which is the reason why state transitions are handled identically for these two transaction types. Based on the payment method and its individual payment flows, timeframes for each state transition may vary as well as the meaning behind some of the status. Both debit and capture transactions are initially CREATED and will result in a final state- either in a successful or in a failed one.

Note: Especially in the async flow (but not limited to it), a status update might come in through backchannel/processor notification service (eg IPN for paypal). These updates will change the evasion transaction state as descibed in the table, even after checkout has happened.

State transitions: preauth

Transaction type preauth (preauthorisation) is a non-booking reservation on the according customers payment instrument. It needs to be captured by the merchant, either through API or using the Payengine Merchant Center. A preauth is handled quite similarly to both debit and capture with regards to state transitions, the most important differences are expiration times and the lack of final status SUCCESS (which expresses that funds have been successfully transferred which is not the case within a preauth).

State transitions: cancel & refund

Whereas cancel allows you to reverse a non-booked transaction (i.e. a preauth) only, a refund is the equivalent for booked transactions (i.e. debit and capture).