Historique de la page

Regularization process

We describe in this page the means implemented to ensure consistency between the IS payment methods and Payline.

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 data received from the payment method

Treatment of non-responses and inaccessibilities of the means of payment

If the payment partner IS does not answer or the connection goes back online, Payline makes new attempts.

The maximum number of attempts depends on the method of payment.

When the last attempt fails, the means of payment is said to be inaccessible.

In this case, Payline:

• refuses the transaction from the merchant and the buyer if the past operations have had no financial impact (ERROR status, with an error code specifying that the payment method is inaccessible);
• refuses the transaction and initiates a recovery process if there is a potential financial impact (ERROR status with return code specifying that a recovery is necessary).

The ability to relaunch demand depends both on the type of transaction and the means of payment.

Treatment of non-compliant responses

We are talking about non-compliant response when the response received does not allow Payline to continue processing. This is the case, for example, when the means of payment uses an unplanned / documented code, does not return an expected parameter or with an empty or non-planned value, etc.

On receipt of a non-compliant reply from the means of payment, Payline:

•  refuses the transaction from the merchant and the buyer if the past operations have had no financial impact (ERROR status, with an error code indicating the error encountered);
• refuses the transaction and initiates a recovery process if there is a potential financial impact (ERROR status with return code specifying that a recovery is necessary).

Payline Internal Error Recovery

On internal error Payline engages the following actions:

• refuses the transaction from the merchant and the buyer if past transactions have had no financial impact (ERROR status, with an 'internal error' code);
• refuses the transaction and initiates a recovery process if there is a potential financial impact (ERROR status with return code specifying that a recovery is necessary).

Return of the buyer on the pages of Payline by the browser

If the buyer returns to the pages of Payline using the browser's return page function and the payment web token is not expired, Payline queries the payment method to know the status of the file and sets update the data TRANSACTION in BD.

If the payment record is processed (everything except IN_PROGRESS) then Payline:

• Returns the buyer on step 3 and / or the merchant's pages;
• Notifies the end of the payment to the buyer and the merchant in accordance with the point-of-sale configuration.

If the file is IN_PROGRESS and the payment web token is not expired Payline returns the buyer to the payment method pages.

If the payment web token has expired, Payline displays a message stating that the maximum payment period has passed and that the buyer must start paying again. Payline can not return to the merchant's pages

Treatment of the absence of return of the buyer

Payline detects the absence of return of the buyer on its pages at the end of the payment web session.

Payline queries the status of the payment file with the payment partner.

If the payment record is processed (everything except IN_PROGRESS) then Payline:

• updates the TRANSACTION data according to the received state;
• Notifies the end of the payment to the buyer and the merchant in accordance with the point-of-sale configuration.

If the file is still pending on the payment side, Payline:

• passes the transaction to status status ABORTED with return code 02013
• Notifies the end of the payment to the buyer and the merchant in accordance with the point-of-sale configuration.

Treatment of the absence of update

Some means of payment do not allow Payline to know the final state of the transaction after a given time (because no notification of the partner following the analysis of the request for funding).

These transactions fail to state ERROR with return code 02015 - transaction delegated to partner

Other transactions have a temporary state at the end of the transaction. It is the partner who notifies Payline of the evolution of the state of this transaction. During the wait, the transaction switches to the ON_HOLD_PARTNER state with the 02016 return code.

Treatment of reconciliation inconsistencies

It's about identifying and dealing with cases where reconciliation reports a payment made while Payline has not treated it as such.

Payline assigns an 'ERROR' state to this transaction with a return code specifying that it is 'manually resume' by the Payline platform team.

Code retour : ‘02009’ ERROR,

However, this case should not occur because Payline makes sure to have a return from the partner before finalizing the transaction.

And, in the case where this finalization can not be carried out, the transaction is placed in the state "To be reversed in fallback mode".

Code retour : ‘02013’ ERROR,

Adjustment of transactions in technical error

A batch periodically retrieves the transactions to be straightened (TO_BE_REVERSED).

The actions to be taken depend on the means of payment.

They may, however, be formalized according to the following characteristics of the means of payment:

• Querying the status of a transaction
• Function to cancel an authorization and refund a payment

• If the payment method has a function to query the status of a payment, Payline:

Query the status of the transaction to straighten

If the transaction is accepted partner side, Payline makes a request for cancellation of the authorization or even a request for refund of payment.

Otherwise, Payline does not request any action from the partner

Payline transfers the transaction to 'REVERSE' if the cancellation or refund request is executed correctly or if the transaction status does not require any adjustment.

The cancellation or refund request must be associated with the original authorization (as for the synchronous part).

• If the means of payment does not have the function of querying the status of a payment, Payline requests via a degraded procedure successively:
  1. The cancellation of the application for authorization;
  2. The refund of the payment.

Payline passes the transaction to 'Recovery' (REVERSED) if

• • the cancellation or refund request is executed correctly;
  • both requests return the result: state incompatible with the request.

• If the payment method has neither the payment status inquiry function nor the cancellation and / or refund functions, Payline transfers the transaction to 'A manually reset' (TO_BE_REVERSED_IN_FALLBACK_MODE)

• If during processing, the payment method does not respond as described above, the transaction being processed is not modified so that it can be processed again at the next pass of the adjustment process.
• If the transaction has not been rectified after a period of time specific to the payment method, Payline transfers the transaction to 'A manually reset' (TO_BE_REVERSED_IN_FALLBACK_MODE).

Treatment of manual adjustments

Periodically, Payline establishes for each means of payment the two payment lists 'A manually rectify':

1. by the means of payment (TO_BE_REVERSED_IN_FALLBACK_MODE)
2. by the Payline platform team (TO_BE_REVERSED_IN_FALLBACK_MODE) è case that should not occur (see end §1.8.3.6)

The information to put together

List of information currently identified:

- external_id Payline

- reference of the order

- partner_unique_id (reference of the trs in the SI partner)

- amount

- timestamp

- trading id

- corporate_name

- card_code

- buyer's details

The treatment

It consists in identifying all the transactions with the status "TO_BE_REVERSED_IN_FALLBACK_MODE".

This search is carried out on sliding 10j (so on the nominal).

Several arguments can be made:

- card_code => if specified as input, only transactions related to this card_code are reported and transmitted. If absent, all transactions are taken into account, without distinction.

- day_partition / month_partition => default, will be absent. However, this will allow targeted extraction if needed; even use on the basis of historization

The result of the treatment is rendered in a file in CSV format. If more than one card_code is requested, the transactions will be grouped by card_code. Within groups, transactions are sorted from the most recent (top of the group) to the oldest (bottom).

Frequency

The treatment is done daily, launched around 6am.