Content
The states of web payments
The state ('state' of the message) of a payment is returned in the result.shortMessage field.
state | comments |
ACCEPTED | Payment is accepted (final state) |
REFUSED | Payment is refused (final state) |
ABORTED | Payment has been abandoned (end state) For example : - A click on the 'cancel' button - A return on the pages of the merchant via the previous button of the browser - A closing of the browser before the termination of the payment |
ERROR | The payment was abandoned due to an unrecoverable technical error. Payline proceeds to a regularization with the means of payment. (final state) |
PENDING_RISK | Payment accepted with reservation. (Temporary state) The merchant must validate or refuse the payment. For example : - the anti-fraud module suspects a fraudulent transaction that must be blocked - Payment 'pending risk' Paypal (where the merchant must perform an action on the PayPal backoffice) |
ONHOLD_PARTNER | The payment was paid by the payment partner and put on hold for later decision-making (temporary state) The final decision (accepted or refused) will be communicated by the partner without intervention of the merchant. for example - Credit file under review - Coupon to validate (Ex: Boleto), - Payment 'pending' Paypal |
INPROGRESS | The buyer is being seized (temporary state) |
Lifecycle of a payment web
The life cycle of a web payment is schematized below:
To understand the changes of state, we summarize in the table below the events that trigger them.
Transition | comments |
INPROGRESS to ACCEPTED | - The partner has accepted the payment. |
INPROGRESS à REFUSED | - The transaction is refused and the buyer has not voluntarily made or can not make a new attempt |
INPROGRESS at ABORTED | - Click of the buyer on the button 'Abort the payment' - The buyer closes his browser before the end of the payment - The buyer returns to the merchant's pages using the browser's back button without completing the payment |
INPROGRESS à ERROR | - Detection of a technical error during payment and the buyer can not or no longer retry - Payline can not know the partner's decision (return code 02015) |
INPROGRESS à ONHOLD_PARTNER | - The partner responds to Payline that a response will be given later by a notification mechanism or equivalent. |
INPROGRESS à PENDING_RISK | - The Payline anti-fraud module suspects a fraudulent transaction that must be put on hold for a risk analysis by the merchant. - The partner responds to Payline that the payment is blocked pending a risk analysis by the merchant. |
ONHOLD_PARTNER à ACCEPTED | - The partner responds to Payline that the request is accepted. |
ONHOLD_PARTNER à REFUSED | - The partner answers to Payline that the request is refused. |
ONHOLD_PARTNER à ERROR | - Detection of an internal technical error or during communication with the partner. |
PENDING_RISK à ACCEPTED | - The merchant accepted the payment. |
PENDING_RISK à REFUSED | - The merchant refused the payment. |
PENDING_RISK à ERROR | - Detection of an internal technical error. |
INPROGRESS to INPROGRESS | - Receipt of a refusal from the payment partner and another possible attempt - Communication error with the payment partner and another possible attempt |
Payment period
For security reasons, Payline manages a maximum time given to the consumer to make his payment.
This delay is by default 30 minutes but can be configurable by the merchant for each point of sale between 10 minutes and 90 minutes.
The initialization of this delay starts with the call to the initialization function doWebPayment.
The supervision of this delay stops when the payment leaves the status "in progress" or when the maximum duration of payment defined by the merchant is reached.
In this way, Payline guarantees a definitive answer in a fixed time: the payment timeout.
The operating principle at the end of the payment period is as follows:
- Payline checks with the partner of the state of payment,
- If the payment is completed or paid, Payline updates the payment status and informs the merchant
- In the opposite case, Payline registers a canceled payment, informs the merchant and commits, if necessary, a procedure of regularization (cancellation, refund, ...) near the partner.
Events that may cause inconsistencies are related to:
- Non-responses and inaccessibilities of the means of payment;
- Responses of non-compliant means of payment;
- Payline processing errors;
- Buyer's return on the Payline pages using the browser's 'backspace' function;
- Absence of return of the buyer on the pages Payline;
- Inconsistencies between the Payline data and the reconciliations received from the payment method.