WL SIPS DOCS

Release 24.2

go directly to content

Search by keywords

  1. Means of payment
  2. Debit and credit cards
  3. Visa

Visa

To search in the page use Ctrl+F on your keyboard

It is advised to read the following documents before

  • Recommended
    1. 3-D Secure and Payment use cases

    3-D Secure

    Functional, technical documentation and user guides to help you to integrate WL Sips online payment solution.

    Open in new tab 3-D Secure

Introduction

Worldline Sips is a secure multi-channel e-commerce payment solution that complies with the PCI DSS standard. It allows you to accept and manage payment transactions by taking into account business rules related to your activity (payment upon shipping, deferred payment, recurring payment, payment in instalments, etc.).

The purpose of this document is to explain the Visa mean of payment integration into Worldline Sips.

Who does this document target?

This document is intended to help you implement the Visa mean of payment on your e-commerce site.

It includes:

  • functional information for you
  • implementation instructions for your technical team

To get an overview of the Worldline Sips solution, we advise you to consult the following documents:

  • Functional presentation
  • Functionality set-up guide

Understanding Visa and Mastercard payments with Worldline Sips

General principles

Cards in the Visa network is one of the most widespread payment cards in the world, used and issued by banks in more than 200 countries.

Visa offers a range of following cards: Visa, VPay, Visa Electron

Furthermore, the Visa network has established the 3-D Secure programme, to reduce the risk of fraud on customers online purchases. This program ensures, at the time of each online payment, that the card is used by the true cardholder.

To pay with a Visa or MasterCard network card, cardholders have to provide their card details, namely:

  • Card number
  • Expiry date
  • Visual security code called CVV
  • If the cardholder's card and your merchant ID are enrolled in 3-D Secure, the customer will be required to enter a dynamic one-time use code, usually received on their mobile phone.

Acceptance rules

Available functionalities
Payment channels
Internet V Default payment channel
MAIL_ORDER, TELEPHONE_ORDER V
Fax V
IVS V
Means of payment
Immediate payment X
End-of-day payment V Default method
Deferred payment V Limited to 99 days, except for 3-D Secure which is limited to 6 days because of the liability shift rules.
Payment upon shipping V Limited to 99 days, except for 3-D Secure which is limited to 6 days because of the liability shift rules.
Payment in instalments V
Subscription payment V
Batch payment V
OneClick payment V
Currency management
Multicurrency acceptance V
Currency settlement V
Dynamic currency conversion V
Payment remittance in the bank

Payments are remitted to a bank according to the payment terms you set. As standard, the remittance in bank is triggered at night as from 10 pm CET (Central European Time) via a file exchange with the acquirer.

Account verification on your initiative

For INTERNET and MOTO channels, you are allowed to perform an account verification on your own initiative (not conditioned by the deferred payment delay). To do this, you have to set the transaction amount to “0”. Therefore, Worldline Sips will perform an account verification from the acquirer, and the transaction will be stored in the Worldline Sips information system, but won’t be remitted in bank.

Attention: the account verification system must be supported by your acquirer. Otherwise, an attempt to perform an account verification on your initiative will be handled as a standard authorisation request with an amount of “0”.
Cap adjustment in case of an error

During a payment, sometimes the current transaction cannot be finalised. This is the case, for instance, when one of the actors in the banking network encounters a failure when processing an authorisation request. The Worldline Sips server will send a message to cancel the transaction, this is the famous cap adjustment. This message allows the issuing bank to update, if necessary, the cardholder's card outstandings.

Attention: in order to operate, the adjustment cap in case of an error must be supported by the acquirer. The cancellation is prioritized: it is completed even if the adjustment fails.
Lost and stolen cards checking

If you have the required option, a card checking is done using a lost and stolen list provided by the acquirer. This checking will be carried out during the transaction validation or the remittance steps.

If the provided card is in the lost and stolen cards list during the validation, the operation is rejected.

If the provided card is in the lost and stolen cards list during the remittance, the transaction will not be remitted.

Attention: this checking must be supported by your acquirer. The checking prior to validation is carried out only if the transaction was not authorised on the same day but the transaction authorisation is still valid.
Address Verification System (AVS) – UK only
Overview

AVS is an anti-fraud functionality available in some countries like UK and required by merchants. The AVS allows you to retrieve the cardholder’s address and have it checked with the provider of this same card through the bank authorisation message.

The card provider will be able to compare the address provided with the address of his database. Two separate checkings are performed: street information checking and postal code checking.

Please refer to the “Functionality set-up guide” for more information about AVS.

AVS response codes

AVS results are returned to you in the responses through two dedicated fields:

  • avsPostcodeResponseCode
  • avsPostcodeResponseCode

Please refer to the “Data dictionary” for more information about how these fields have their value set.

Reversal request

A reversal request aims to cancel the modification of the issuer authorisation cap.

This reversal request is always linked to an authorisation request.

Tip: the reversal request is available for acquirers accepting it (please contact us to have the list).

The reversal request is sent to the acquirer in the following case:

  • the merchant fully cancels the transaction. The cancellation is prioritized: it is completed even if the reversal fails;
  • the authorisation server doesn't respond positively to an authorisation request for the following reasons: "approved after identification" or "approved for partial amount";
  • no response has been received after an authorisation request (timeout);
Modalities for reattempts on refused authorizations

The Visa and Mastercard schemes may inflict financial penalties to acquirers that would let too many reattempts of the same refused authorizations be retried (with the expectation that they could finally be accepted). As a consequence, acquirers are implementing new fields in their authorization responses when the authorization is refused. This information is intended for merchants so that they take it into account. It indicates under which conditions a reattempt is possible. Worldline Sips sends you this information in the form of the following data:

Field name Description
reattemptMode Condition for a reattempt following a refused authorization
  • NEVER : never retry
  • LATER : retry later
  • UPDATE : update information before retrying (for future use)
reattemptMax Maximum number of allowed reattempts on an authorization during the allowed-reattempt period
reattemptStartDateTime Start date of the allowed-reattempt period
reattemptEndDateTime End date of the allowed-reattempt period

Several cases are possible:

  • reattempting may be disallowed (case: reattemptMode=NEVER) ;
  • reattempting may be disallowed during an initial, frozen period; then be allowed again during the allowed-reattempt period (case: reattemptMode=LATER) ;
  • possibly, a maximum number of allowed reattempts may be specified (reattemptMax) ;
  • finally, a case is provided (reattemptMode=UPDATE), for future use, where the authorization's refusal takes its explanation in some lack of required information. It will be necessary to provide the missing information in the next reattempt.

You can recognize a replayed transaction because it has a refused status (transactionStatus = Refused) and is chained to the original transaction on the same contract with the same amount.

The availability of these data depends on your acquiring contract:

Contract Availability
CB contrat - France NO
Worldline Blue contract - Belgium YES

Signing your Visa acceptance contract

In order to offer the Visa means of payment on your website, you have to sign a distance selling contract with your acquiring bank. Thereafter, you transmit us the contract number for recording in our information system. If you accept INTERNET and MOTO payments, tell your acquirer, because some acquirer will need you to sign 2 separate contracts.

Making a Visa payment

Worldline Sips offers you three solutions to integrate the Visa means of payment:

  • Sips Paypage which directly acts as the payment interface with customers via their web browser.
  • Sips Office which gives you the opportunity to display your payment pages and works through a server-to-server dialog.
  • Sips Office Batch which allows you to process batch payments.

The remittance modes available for a Visa transaction are:

  • Cancellation mode: default mode allowing transaction remittance on a predefined date, called capture delay. When this capture delay is reached, the remittance is sent automatically. This delay is set via the captureDay field with its 0 default value (end-of-day payment).
  • Validation mode: you must validate the transaction to trigger the remittance. A capture delay must also be defined. When this capture delay is reached or exceeded, you will not be able to validate the transaction, which will therefore expire automatically.

The diagram below explains the different transaction statuses according to the chosen capture mode:


description of the possible statuses for a transaction

In cancellation mode (captureMode = AUTHOR_CAPTURE), if the transaction is accepted and the capture delay (captureDay) is not exceeded, the transaction changes to TO_CAPTURE status. If it is exceeded, the transaction changes to TO_AUTHORIZE status. In validation mode (captureMode = VALIDATION), if the transaction is accepted and the capture delay (captureDay) is not exceeded, the transaction changes to TO_VALIDATE status. If the capture delay is exceeded, the transaction is set to TO_REPLAY status. Regardless of the capture mode, if the transaction is rejected (responseCode not equal to 00), it is set to REFUSED status.

Making a Visa payment with Sips Paypage

The payment process for Sips Paypage is described below:


image showing the kinematics of a payment via Paypage

1) After finalizing the order on the merchant website, the customer proceeds to the payment. 2) The customer is redirected to the payment pages hosted on the Worldline Sips side and selects Visa. 3) The customer is redirected to the ACS of his bank to do a strong authentication. 4) When the customer returns to Worldline Sips the ticket with the result is displayed. 5) If the customer clicks on the return to shop button, they are redirected to the merchant's website which unlocks the manual response. 6) The Worldline Sips engine also sends an automatic response to the merchant website.
Setting the payment request

The following fields have a particular behaviour:

Field name Remarks/rules
statementReference The value sent to this field will appear on your account statement (Available only for some acquirers).
Note: the field paymentMeanBrand can be set to VISA.
Analysing the response

The following table summarises the different response cases to be processed:

Status Response fields Action to take
Payment accepted acquirerResponseCode = 00
authorisationId = (cf. the Data Dictionary).
cardProductCode = (cf. the Data Dictionary).
cardProductName = (cf. the Data Dictionary).
cardProductProfile = (cf. the Data Dictionary).
cardProductUsageLabel = (cf. the Data Dictionary).
virtualCardIndicator = (cf. the Data Dictionary).
issuerCode = (cf. the Data Dictionary).
issuerCountryCode = (cf. the Data Dictionary).
paymentMeanBrand = VISA
paymentMeanType = CARD
responseCode = 00
 You can deliver the order.
Acquirer refusal acquirerResponseCode = (cf. the Data Dictionary).
responseCode = 05
 The authorisation is refused for a reason unrelated to fraud.
If you have not opted for the "new payment attempt" option (please read the Functionality set-up Guide for more details), you can suggest that your customer pay with another means of payment by generating a new request.
Soft decline acquirerResponseCode = A1
responseCode = 05
 The acquirer has refused the payment because there was no 3-D Secure authentication.
Please try the payment again by activating the 3-D Secure authentication.
Refusal due to the number of attempts reached responseCode = 75 The customer has made several attempts that have all failed.
Refusal due to a technical issue acquirerResponseCode = 90-98
responseCode = 90, 99
 Temporary technical issue when processing the transaction. Suggest that your customer redo a payment later.

For the complete response codes (responseCode) and acquirer response codes (acquirerResponseCode), please refer to the Data dictionary.

Making a Visa payment with Sips Office

The payment process for Sips Office is described below:


steps of an American Express payment via Office

1) You collect the card information on the payment page hosted on your website and transmit this information to information to Worldline Sips via the cardCheckEnrollment method. 2) Worldline Sips sends you the url of the ACS. 3) You redirect your customer to the ACS. 4) Your client authenticates and is redirected to your site. 5) You collect authentication information and send an authorization request to Worldline Sips via the cardValidateAuthenticationAndOrder method. 6) Worldline Sips sends you the payment response and you display the payment result to your your customer on your website.
Setting the payment request

American Express payments can be initiated using the cardCheckEnrollment function of the CheckOut service. The following fields are used to send information specific to this means of payment:

Field name Remarks/rules
cardNumber Mandatory
cardExpiryDate Mandatory, if specified on the card.
cardCSCValue Mandatory in some countries (3 digits).
The CVV is optional for transactions using the MOTO payment channel.
paymentMeanBrand The paymeantMeanBrand field can be populated with VISA.
Note: if allowed by the acquirer the CVV can be optional for transactions that use the MOTO payment channel.
The paymeantMeanBrand field can be populated with VISA.

For more information, please refer to the 3-D Secure guide on Sips Office connector to implement the other steps of a 3-D Secure payment.

Analysing the response

The following table summarises the different response cases to be processed:

Status Response fields Action to take
Payment accepted acquirerResponseCode = 00
authorisationId = (cf. the Data Dictionary).
cardData.cardProductCode = (cf. the Data Dictionary).
cardData.cardProductName = (cf. the Data Dictionary).
cardData.cardProductProfile = (cf. the Data Dictionary).
cardData.cardProductUsageLabel = (cf. the Data Dictionary).
cardData.virtualCardIndicator = (cf. the Data Dictionary).
cardData.issuerCode = (cf. the Data Dictionary).
cardData.issuerCountryCode = (cf. the Data Dictionary).
cardData.issuerName = (cf. the Data Dictionary).
paymentMeanBrand = VISA
responseCode = 00
 You can deliver the order.
Acquirer refusal acquirerResponseCode = (cf. the Data Dictionary).
responseCode = 05
 The authorisation is refused for a reason unrelated to fraud, you can suggest that your customer pay with another means of payment by generating a new request.
Soft decline acquirerResponseCode = A1
responseCode = 05
 The acquirer has refused the payment because there was no 3-D Secure authentication.
Please try the payment again by activating the 3-D Secure authentication.
Refusal due to a technical issue acquirerResponseCode = 90-98
responseCode = 90, 99
 Temporary technical issue when processing the transaction. Suggest that your customer redo a payment later.

For the complete response codes (responseCode) and acquirer response codes (acquirerResponseCode), please refer to the Data dictionary.

Please refer to 3-D Secure guide to analyse the authentication information.

Managing your Visa transactions

Available cash operations

The following operations are available on Visa transactions:

Cash management
Cancellation V Depending on your acquirer, a total cancellation can cause a reversal request sending.
Validation V Validation available on the partial amount of the transaction.
Refund V Refund available on the partial amount of the transaction and for amounts greater than the initial amount (unlimited refund).
Duplication V
Credit V

The diagram below informs you which cash management operation is available when a transaction is in a given state:


image too complex to be described, please contact the support

Viewing your Visa transactions

Reports

The reports provided by Worldline Sips allow you to have a comprehensive and consolidated view of your transactions, cash operations, accounts and chargebacks. You can use this information to improve your information system.

The availability of Visa transactions for each type of report is summarised in the table below:

Reports availability
Transactions report V
Operations report V
Reconciliations report V
Chargebacks report V
Note: The paymentMeanBrand field is populated with the value VISA.

Sips Office Extranet

You can view your Visa transactions and perform various cash management operations with Sips Office Extranet.



Back to top Need help?

This site uses trackers to improve your experience, perform analysis and researches on your use of WL Sips documentation website.
You have several options:
Closing this banner you refuse the use of trackers on your device.

Configuration