Release note 20.3
This release note gives you a of the functional content of the WL Sips 20R3 release.
It is separated in two parts:
- new additions in the Sips Solution : are listed the modifications of new functionalities added to our offer;
- regulatory changes
If you want to benefit of those new functionalities , please get in touch with your usual Sips contact if you are one of our client. Or, send us a message at the following email address: email@example.com .
Deliveries in production : from the 11 th until the 25 th of March 2020.
New functionalities of the Sips solution for merchants
Acceptance of JCB, CUP and Diners means of payments
WL Sips expands its offer of international means of payment. It now allows you to accept the following cards via Sips Paypage :
- JCB (formerly Japan Credit Bureau) : credit card used in the United States, China, Canada and India;
- CUP (China UnionPay) : card widely used in China;
- Diners (Diners Club International) : international credit card in 59 countries.
UnionPay and Diners cards are offered in “collecting” mode (WL Sweden is both acceptor and in charge of collecting and transferring the amount of transactions).
JCB cards are offered in “distributing” mode (WL Sweden only accepts transactions).
Addind a card to a wallet with Office consequently
It is now possible to add a card to a wallet using the “addCard ” function of the “wallet ” service via our client-side encryption solution (Office CSE) . This way, you can offer your customer to save their means of payment in a wallet without having to manage the processing of sensitive data at your level, all of it being encrypted.
Operation to cancel a transaction in VALIDATION mode
If you are in VALIDATION mode you will now be able to cancel a transaction with the status TO_VALIDATE. You will no longer need to confirm the transaction before cancelling it.
The cancellation operation may be total or partial and relates to all means of payment allowing this cancellation.
The total cancellation operation generates a request to adjust the authorisation limit for the card holder, if this functionality is supported by the acquirer.
This new functionality will be generalised at a later stage. If you would like to take advantage from it now, please get in touch with your usual contact to request activation on your webshop.
CB2A 2019 1.6.0 light
A new version of the CB2A protocol will be available with the 20R3 release. It is called “light” because only the following evolutions are implemented:
- 3DSV2 : addition of fields allowing to address Mastercard
- RTS : TRA exemption for CB
- Card on File : addition of a new value to the reading mode of the card horlder
- OEMPAY : modification of the length of the CAVV
Other upgrades to the 2019 CB2A 1.6 will be taken into account later. As of this version, 3DSv2 is possible on the three networks, CB, Visa and Mastercard.
As a reminder, here is a 3DS / networks summary table:
Acquirer TRA Exemption
A new option in the merchant’s acquirer contract will make it possible to enable or disable the possibility of requesting a TRA (Transaction Risk Analysis) exemption on transactions with strong authentication in the 3DSv2 RTS framework, on the CB network.
Thus, the merchant having activated this option will be able to send the TRA reason in the authentication request in order to get an authentication exemption.
In the event of fraud, the payment responsibility will then be borne by the merchant.
Identification of the A1 code on AMEX
Authorisation refusals on AMEX transactions with a code “130” transmitted via the GCAG field 39, will lead to an “acquirerResponseCode ” set to “A1” and no longer “05”.
Thus AMEX transactions with an authorisation refusal linked to a “Soft Decline” can be identified.
|42979||Back Office||Technical||The French acquirer contract number is reduced to 7 positions in the bank reconciliations report in order to align with the CB2A format, to harmonize the format of the WL Sips reports and to facilitate their processing on the merchant side.||Trivial|
|44280||Paypage||Fonctional||Perform verification at the finalisation level of the payment session so as not to propose a new payment attempt if a finalisation is already in progress.||Major|