Versions Compared

Old Version 47

changes.mady.by.user Søren Duusgaard (Deactivated)

Saved on

compared with

New Version 48

changes.mady.by.user Søren Duusgaard (Deactivated)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

The possible transitions a payment is able to A payment can be part of a number of , transitions which may be split into a number of overall steps:

  • authorization , where - the payment is validated and the amount is possible possibly reserved on the customer account.
  • capture , where - the reserved amount is actually transferred from customer account to the client account.
  • cancel , where - an authorization may be cancelled.
  • refund , where - a captured payment may be refunded (initiated by Rator).

To get an overview of valid transitions, see the following diagram.

Please note , that from all state states it is possible to enter the error state, and from the error state it is possible to return to another state . This - this is not shown in this the diagram.

The green arrows indicate transitions initiated by our business processes. This covers requesting a cancellation, a capture or a refund. In order to support to be able to enter re-entering the do_auth state again, it is also possible to request an authorization.

...

The red dashed arrows indicate transitions initiated by the payment gateway. These transitions happens occur when the communication is a-synchronous and thus the response arrive 'later', not coupled directly to the previous request.

Section
Column

Authorization steps

doAuthorize

when a payment is created, it is always created with this status. This indicates that the payment should be validated and possible the amount reserved.
The payment will either be picked by Rator logic initiating the authorization, or it may be requested cancelled.

authorizeSent

When the authorization request is sent to the payment gateway, the actual communication may be delayed. In this case the payment gateway will indicate this with this state.
The payment will stay in this state, until the payment gateway receives information about the next state.

authorized

The authorization request is processed and the money is reserved. This will be reflected financially in the Rator system by creating appropriate detail lines.
The payment will stay in this state, until business logic or users request either a cancellation or a capture.

rejected

The authorization request is processed but the money could not be reserved. This could be caused by missing funds, wrong credentials, etc. This will be reflected financially in the Rator system by possible creating appropriate detail lines that will revert any previously created detail lines.
The payment is no longer active. In case a new authorization is needed, a new payment must be initiated.

Column

Cancellation steps

doCancel

The ongoing authorization is requested to be cancelled.
The payment will be picked up by Rator logic that will initiate the actual cancellation.

cancelSent

When the cancellation request is sent to the payment gateway, the actual communication may be delayed. In this case the payment gateway will indicate this with this state.
The payment will stay in this state, until the payment gateway receives information about the next state.

cancelled

The cancellation request is processed and the previous authorization is cancelled. This will be reflected financially in the Rator system by possible possibly creating appropriate detail lines that will revert any previously created detail lines.
The payment is no longer active. In case a new authorization is needed, a new payment must be initiated.

Column

Capture steps

doCapture

The previous authorization is requested to be captured.
The payment will be picked up by Rator logic that will initiate the actual capture.

captureSent

When the capture request is sent to the payment gateway, the actual communication may be delayed. In this case the payment gateway will indicate this with this state.
The payment will stay in this state, until the payment gateway receives information about the next state.

captured

The capture request is processed and the previous authorization is fulfilled.
The payment will in most cases never leave this state, so effectively the payment is considered completed. However, business logic or users may request the payment to be refunded, as well as the third party may initiate the payment to be withdrawn.

rejected

The capture request is processed but the money could not be transferred. This could be caused by account being terminated or blocked, or the previous authorization has expired. This will be reflected financially in the Rator system by creating appropriate detail lines that will revert any previously created detail lines.
The payment is no longer active. In case a new authorization and capture is needed, a new payment must be initiated.

withdrawn

The capture request is completed, but the third party have has initiated the payment to be withdrawn. This will be reflected financially in the Rator system by creating appropriate detail lines that will revert any previously created detail lines.
The payment is no longer active. In case a new authorization and capture is needed, a new payment must be initiated.

Column

Refund steps

doRefund

The previous captured is requested to be refunded.
The payment will be picked up by Rator logic that will initiate the actual refund.

refundSent

When the refund request is sent to the payment gateway, the actual communication may be delayed. In this case the payment gateway will indicate this with this state.
The payment will stay in this state, until the payment gateway receives information about the next state.

refunded

The refund request is processed and completed successfully.