Page tree
Skip to end of metadata
Go to start of metadata


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:

  1. Payline checks with the partner of the state of payment,
  2. If the payment is completed or paid, Payline updates the payment status and informs the merchant
  3. 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.