...
To get an overview of valid transitions, see the following diagram.
Drawio |
---|
diagramName | Account Payment capture status overview.drawio |
---|
revision | 1 |
---|
|
Please note that from all states it is possible to enter the error state, and from the error state it is possible to return to another state - this is not shown in the diagram.
...
Section |
---|
Column |
---|
Authorization stepsdoAuthorizeWhen a payment is created, it is always created with this status. This indicates that the payment should be validated and the amount possibly reserved. The payment will either be picked by Rator logic initiating the authorization, or it may be requested cancelled. authorizeSentWhen 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. authorizedThe 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. rejectedThe 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 stepsdoCancelThe ongoing authorization is requested to be cancelled. The payment will be picked up by Rator logic that will initiate the actual cancellation. cancelSentWhen 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. cancelledThe cancellation request is processed and the previous authorization is cancelled. This will be reflected financially in the Rator system by 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 stepsdoCaptureThe previous authorization is requested to be captured. The payment will be picked up by Rator logic that will initiate the actual capture. captureSentWhen 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. capturedThe 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. rejectedThe 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. withdrawnThe capture request is completed, but the third party 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 stepsdoRefundThe previous captured is requested to be refunded. The payment will be picked up by Rator logic that will initiate the actual refund. refundSentWhen 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. refundedThe refund request is processed and completed successfully. partially_refundedThe partial refund has been completed successfully. The partial refund is only available from core 9.10 if it is supported by the specific payment gateway in use. |
Column |
---|
Payout stepsA payout is the case, where money is to be transferred from the customer BillingGroup balance to his/her bank account. A payout will create a negative InvoiceDetailLine. Please note that the payout flow is a separate process. DO_PAYOUTdoPayoutAccountPayments can be created and set in status DO_PAYOUT . This will make the AccountPayment visible for an engine, that handles payouts. PAYOUT_SENTpayoutSentWhen the payout 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. PAID_OUTpaidOutThe payout request is processed and completed successfully. The service class AccountPaymentSetIsPaidOut is called in order to: - Update the status of the AccountPayment to PAID_OUTpaidOut.
- Create an InvoiceDetailLine.
payoutRejectedThe request for payout is rejected by the payment gateway. Reasons could be that the indicated account number or credit card no longer is available. payoutWithdrawnThe previously paid out payment is now withdrawn. This could happen if the payment was marked as successfully paid out, but later the customer or bank rejected the payment anyway. |
|