WL SIPS DOCS

Release 22.3

go directly to content

Search by keywords

Subscription payment via wallet

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

It is advised to read the following documents before

  • Recommended

    MIT/CIT chaining

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

    Open in new tab MIT/CIT chaining

WL Sips is a secure, multichannel 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 implementation of the subscription-based payment solution up to the start of production.

This document is intended to help you implement the recurring payments for the services they provide to their customers (hereinafter referred to as subscribers).

The purpose is to present the features of subscription payments and explain how to implement them with the WL Sips solution.

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

  • Functional presentation
  • Functionality set-up guide
Note: WL Sips does not manage the subscribers personal details (first name, surname, address, age, email, telephone, etc.), just the payment details that let you debit or credit your subscribers.

Subscription payments require your subscribers' payment details to be stored by WL Sips to ensure that you can make payments.

Therefore, here are some points to address before you can get started:

  • To comply with the GDPR, you must complete your internal personal data processing register, specifying that the card details are stored in WL Sips platform. For more information on the GDPR, please refer to our Sips information systems security.
  • Inform your customers that their recurring payment details and methods will be stored (duration, amount, frequency etc.).
  • Check with your acquirer that your contract supports recurring payments.

For any technical question or request for assistance, our services are available:

  • by telephone at: +33 (0) 811 10 70 33
  • by e-mail: sips@worldline.com

In order to facilitate the processing of your requests, please provide your merchantId (15-digit number).

When you record a subscriber in your information system, you should allocate a unique account ID that WL Sips will use to store the subscriber's payment details. You can then debit the subscriber on a recurring basis by file transfer or in online mode.

Diagram showing the principle of subscription payments with a card:


image of the diagram showing the principle of subscription payments

The merchant keeps in its information system a customer identifier to which it associates a subscriber identifier. When making a debit or credit, the merchant sends to WL Sips a request containing the subscriber identifier. WL Sips will retrieve the payment details stored in the database attached to this identifier to make the debit or credit request to the acquirer.

You manage the subscriber's ID, which is associated to your customer's account. WL Sips stores the subscriber's payment details in a secure PCI space called a wallet.

The diagram above also applies to subscription payments with an SDD mandate.

In this case, WL Sips stores the mandate ID in the wallet database.

The subscription service is based on the WL Sips wallet, a secure virtual wallet, where the subscriber's payment details are stored:

The payment methods compatible with recurring payments are:

  • Carte CB, Visa, Mastercard, Amex, Bancontact (WIP feature required)
  • Mandat SDD (SEPA Direct Debit).

WL Sips stores in the wallet all the information you need to debit your subscriber based on their User ID:

  • CB, Visa, Mastercard, Bancontact, Amex
    • Card number
    • Expiry date
    • Card brand
  • SDD mandate
    • Mandate ID
Note: every webshop has its own subscriber database by default.

However, WL Sips allows the same wallet database to be shared among several webshops of the same brand.

If this applies to you, please contact technical support.

The subscriber enrollment involves recording subscriber payment details in the WL Sips wallet. The enrollment may or may not be associated with a first payment.

Subscribers can be enrolled via 2 interfaces:

  • Sips Paypage: you save the subscriber's payment details when the first payment is made from pages hosted by WL Sips.
  • Sips Office M2M: you manage your own pages for entering payment details and you use the online web interface to record the subscriber in the WL Sips wallet.
Note: For CB, VISA, Mastercard network, the "brand selection" should also be applied in wallet kinematics. The brand selection status should be stored on the enrollment step. But, unlike oneclick process, the brand selection cannot be changed when doing a subscriber payment. For more information, please look at this guide

Recurring payments are then made based on the subscriber's ID (merchantWalletId field) without you having to communicate any sensitive information.

Subscribers can be debited or credited via 2 types of interfaces:

  • Sips Office M2M: you connect to WL Sips via an online web interface for transmitting debit or credit requests.
  • Sips Office Batch: on each due date, you transfer a file to WL Sips containing the debit or credit requests of the subscribers.

Since the subscription service is based on a single payment method wallet (1 wallet = 1 payment method), wallet management consists of the :

  • replacement of a payment method by deleting the existing wallet and creating a new one .
  • removal of a wallet and the payment details at the request of the subscriber (legal obligation).

Expired payment mean :

  • payment means (and associated wallets) expired from more than 3 months, are automatically removed from the wallet database

In the subscription payment process, you should authenticate your customers before accessing the subscriber IDs stored in your customer database.

Once the authentication has been made, you transmit the WL Sips subscriber ID in the request via the merchantWalletId field.

Your management of the subscriber IDs attributed to your customers should:

  • guarantee a 1-1 relationship between the subscriber and the customer (1 customer = 1 subscriber) .
  • allow the storage of subscriber IDs.
Attention: you are responsible for subscriber authentication.

WL Sips manages the secure storage of subscriber payment details.

To maintain the corporate identity of your e-commerce website, the Sips Paypage and Sips Walletpage interfaces can be customised.

Please view the Page Customisation Guide for more information.

We encourage to use the version TAB20_V21 or higher of the transaction reports, in order to locate the merchantWalletId and the schemeTransactionIdentifier field.

To manage expired cards, use the expired cards report.

For more information, please see the Reports Description Guide.

In order to process the next subscription due dates (MIT) and to be able to link them to the CIT, please keep the merchantWalletId.

Given that WL Sips offers several interfaces for enrolling subscribers and processing payments, it is worth assessing your business requirements in order to select the connectors best suited to your situation.

The table below helps you make your choice.

Use cases Sips Paypage Sips Office Sips In-App Sips Office Batch Sips Walletpage Sips Office Extranet BackOffice Recommendations for choosing the interface
Management of the enrollment pages
You outsource the pages for entering payment details to avoid the PCI requirements. V X X X X X If you use Sips Paypage to process your payments, you can take advantage of this existing integration to manage your subscriber enrollment. Otherwise use the Sips Walletpage to enrol your subscribers.
You manage the pages for entering payment details that you integrate into your subscriber enrollment process. X V V X X X Sips Office meets your e-commerce requirements. For m-commerce, we encourage the use of Sips In-App.
Debiting or crediting the subscriber
You debit or credit your subscribers at fixed intervals (e.g. flat rates or services billed after consumption). X V X V X X The Sips Office Batch file mode is the connector used for the periodic batch processing of subscriber payments, but you could use Sips Office too.
You debit or credit your subscribers at varying intervals (e.g. prepaid services or the subscriber has to add money to the account before consumption). X V X X X X The Sips Office transactional mode is the connector used for debiting or crediting your subscribers at varying intervals.
Managing subscribers
Updating the subscriber's payment method The update is processed like a subscriber enrollment by registering the payment details in a new wallet. Reuse the same connector as the one to enrol subscribers.
Deleting the subscriber X V V V V V Use Sips Office if you want the option to delete in real time and Sips Office Batch if you do not. If you do not want to automate this function, you can delete your subscribers from the BackOffice WL Sips.
Initialisation of the subscriber database
You migrate an existing database. X X X V X X Sips Office Batch allows you to initialise the subscriber database from an existing database.

To implement WL Sips subscriptions, you should get a suitable Connector Guide.

This is a typical Sips Paypage payment process, where the payment details are recorded in the wallet if the transaction is accepted.


image showing the page in the case of an accepted transaction

The following message is displayed : your payment has been accepted. We advise keeping your payment details. Your payment mean was registered.

diagram showing the steps of the payment via Paypage with registration in a wallet

  1. To record the subscribers' payment details, you should redirect them to Sips Paypage, sending the transaction data in the request (amount, currency, etc.), as well as the subscriber ID (merchantWalletId field).
  2. WL Sips displays the payment page, the subscriber provides their payment details, then confirms.
  3. WL Sips makes a 3-D Secure verification.
  4. WL Sips makes anti-fraud checks.
  5. WL Sips sends an authorisation request to the Acquirer.
  6. WL Sips records the transaction in the back office.
  7. If the transaction is approved WL Sips records the subscriber payment details in the wallet.
  8. WL Sips displays the payment receipt page with a confirmation message that the subscriber payment method has been registered.
  9. WL Sips returns the manual and automatic responses containing the transaction details, including the result of the subscriber registration in the wallet.
  10. WL Sips may or may not send the transaction for collection, depending on the parameters that you have configured in the payment request.
Note: due to regulatory constraints, you should first inform the subscriber that the means of payment is recorded and refer to the relevant CNIL notices.

Make a classic payment Sips Paypage request as described in the connector guide.

However, the following field should be valued as follows:

Field Value
merchantWalletId subscriber ID

For subscriptions with cards only (DSP2 obligation, see chaining documentation for more information), the following fields have a special behaviour and have to be filled in like this:

Field Value
paymentPattern RECURRING_1
captureDay 0 to 6
captureMode AUTHOR_CAPTURE or VALIDATION
amount amount of the first payment, can be valued at 0 (if the 1st month of the subscription is free for example).
authentAmount to be valued if the amount field = 0 with the average amount of a payment occurrence of the subscription.

If the field is not filled in, the authentication amount will be the same as the one indicated in the amount field.

ChallengeMode3DS forced to CHALLENGE_MANDATE (strong authentication required for CB, VISA, MC and AMEX payment methods before adding the card to the wallet)

WL Sips returns a typical Sips Paypage manual and automatic response.

The fields related to subscriber enrollment are as follows:

Status Response fields Actions to be performed

Transaction accepted

Subscriber enrolled

responseCode = 00

acquirerResponseCode = 00

paymentMeanId = 1

merchantWalletId = idem request

Store the following customer details in your subscriber database:

You can submit recurring payments.

Transaction accepted

Subscriber not enrolled

responseCode = 00

acquirerResponseCode = 00

paymentMeanId = non renseigné

merchantWalletId = idem request

The transaction was accepted but a temporary technical problem occurred during enrollment of the payment method in the wallet.

Transaction declined

Subscriber not enrolled

responseCode = XX (différent de 00) Please refer to the Sips Paypage Connector Guide to analyse the WL Sips response.

Before recording the payment method in the wallet, you should have to check it first via a standard payment request.


diagram showing the steps of the payment via Office with registration in a wallet

You manage the data entry for payment methods on your website.

  1. Step 1: You send a request to WL Sips to verify the payment method before enrolling the customer.
    • The 3-D secure authentication to verify that the customer is the cardholder of CB, Visa, Mastercard, Amex, Bancontact cards.
    • Anti-fraud checks that you have configured according to your business rules (e.g. foreign cards, commercial cards, etc.).
    • Authorisation request to the acquirer to verify that the card is still valid (not stolen, lost etc.).
      1. WL Sips records the transaction.
      2. WL Sips may or may not send the transaction for remittance to the acquirer, depending on the elements provided in the request.
    • WL Sips sends you the results of the payment methods verification.
  2. Step 2: Once the payment method has been verified, you send a second request to WL Sips to register the payment method in the wallet.

  3. WL Sips returns the payment method registration response.

The sequence described above applies to the Amex, Oney, SDD and Bancontact means of payment.

Use the methods below, depending on the verification level of the payment method to be enrolled.

CB, Visa, Mastercard, Bancontact, Oney, AMEX cards

Wallet service methods Type of action
addcard Adding a card to the wallet

SDD mandate

Méthodes du service wallet Type of action
addDirectDebit Adding a mandate to the wallet

Please refer to one of the Sips Office guides corresponding to the selected connector (JSON or SOAP), as well as the Payment methods guides, to learn how to populate the request, depending on your business requirements.

When receiving the answer, before analysing it and following the advice in the table below, check the seal. The recalculated seal must be identical to the seal received.

CardOrder, cardValidateAuthenticationAndOrder and directDebitOrder methods

Status Response fields Action to take
Transaction accepted

responseCode = 00

acquirerResponseCode = 00

Store in your information system the field schemeTransactionIdentifier

You can register the card for the wallet using the addcard or addDirectDebit method.
Transaction refused responseCode = XX Tell the customer that their card number is invalid and ask them to enrol another payment method.

Use the methods below, depending on the payment method to be enrolled. The merchantWalletId field contains the customer ID.

Carte CB, Visa, Mastercard, Bancontact, Oney, Amex

Wallet service methods Type of action
addcard Adding a new card to the wallet

SDD mandate

Wallet service methods Type of action
addDirectDebit Adding a mandate to the wallet

Please refer to the adequate Sips Office guide, as well as the Payment methods guides, to learn how to populate the request, depending on your business requirements.

Status Response fields Action to be performed
Subscriber enrolled

walletReponseCode = 00

paymentMeanId = 1

You can debit or credit your subscriber

Subscriber not enrolled

Invalid request

walletReponseCode = xx

paymentMeanId = not populated

Please refer to the Sips Office Connector Guide to analyse the WL Sips response

Once the subscriber is registered, you can debit him/her in offline mode with Sips Office Batch.


Diagram showing the steps of a debit via Office Batch

You format a Sips Office Batch file using the WalletOrder method.

Each WalletOrder registration contains:

  • The ID of the subscriber to be debited (merchantWalletid field).
  • The transaction data (amount, order reference etc.).
  1. You send the file to Sips via FTPS or SFTP.
  2. WL Sips retrieves the subscriber payment details stored in the wallet.
  3. WL Sips executes the anti-fraud checks that you configured for your store.
  4. WL Sips sends the authorisation requests to acquirers.
  5. WL Sips stores the transaction in the back office.
  6. WL Sips formats the response file and sends it to you.
  7. In the evening, WL Sips sends the payment collection of accepted transactions.

Please consult the Sips Office Batch XML or Sips Office Batch CSV guides to find out more about implementation (file structure, description of records, file transfer, error management etc.).

To generate a recurring subscription payment using the walletOrder method, you should complete the following fields:

Field Value Comment
merchantWalletID ˂Subscriber ID˃
paymentMeanId 1 The payment method ID in the wallet is mandatory even though the wallet contains only one payment method.

Please refer to Sips Office Batch XML or Sips Office Batch CSV Guides to learn how to complete the other fields for the request, depending on your business requirements.

For payments with cards, the fields below have a particular behaviour and should be valued like this:

Field Value Comment
paymentPattern RECURRING_N Recurring payment to indicate to the acquirer that there is no 3-D Secure data and CVV.
cardCSCValue Not populated
initialSchemeTransactionIdentifier value of the schemeTransactionIdentifier field received when the subscription was taken
Status Response fields Action to be performed
Transaction accepted responseCode = 00 Check the next day in the transaction log that the payment has actually been sent (transactionStatus = CAPTURED)
Transaction declined responseCode = XX Please refer to the Sips Office Batch Connector Guide to analyse the WL Sips response.

The Sips Office JSON/SOAP connector also offers the walletOrder method in message mode with the same rules involved in formatting the request and analysis of the response.

Please refer to Sips Office to find out more about the implementation.

You can credit a subscriber based on their ID without reference to an initial debit transaction.

Note: this feature is supported only by CB, Mastercard and Visa cards.

Diagram showing the steps of a credit via Office Batch

The Sips Office Batch solution allows batch payments to be made.

You format a Sips Office Batch file using the walletCredit method.

Each walletCredit record contains:

  • The ID of the subscriber to be debited (merchantWalletOrderId field)
  • The transaction data (amount, order reference etc.).
  1. You send the file to WL Sips via FTPS or SFTP.
  2. WL Sips retrieves the subscriber payment details stored in the wallet.
  3. WL Sips sends the authorisation requests to acquirers.
  4. WL Sips stores the transaction in the back office.
  5. WL Sips formats the response file and sends it to you.
  6. In the evening, WL Sips sends the payment collection of accepted transactions.

Please consult the Sips Office Batch XML or Sips Office Batch CSV guides to find out more about implementation (file structure, description of records, file transfer, error management etc.).

To generate a recurring subscription payment using the walletCredit method, you should complete the following fields:

Field Value Comment
merchantWalletID ˂subscriber id˃
paymentMeanId 1 The payment method ID in the wallet is mandatory even though the wallet contains only one payment method.

Please refer to Sips Office Batch XML Sips Office Batch CSV guides to learn how to complete the other fields for the request, depending on your professional requirements.

Status Response fields Actions to be performed
Transaction accepted responseCode = 00 Check the next day in the transaction log that the payment has actually been sent (transactionStatus = CREDITED)
Transaction denied responseCode = XX Please refer to the Sips Office Batch Connector Guide to analyse the WL Sips response

The Sips OfficeJSON/SOAP connector also offers the option to credit a subscriber using the walletCreditHolder method in message mode.

The rules involved in formatting the request and analysis of the response are the same as those for Sips Office Batch.

Please refer to Sips Office to find out more about the implementation.

The Sips Walletpage interface allows the subscriber to autonomously manage his wallet. The following features are available:

  • consulting the contents of a subscriber account
  • editing the payment mean of a subscriber account (alias only)
  • removing a subscriber account

All management features are available to the user by default. However, it is possible to reduce the scope of these features, by indicating the list of features required in the walletActionNameList field.

For the wallet management you should populate the fields below:

Field Value
merchantWalletId Customer ID
walletActionNameList Value like this: SIGNOFF,UPDATEPM

Please refer to the Sips Walletpage guide corresponding to the selected connector (JSON, POST or SOAP) to learn how to populate the request, depending on your business requirements.

Status Response fields Action to take
Customer removed walletPaymentMeanDataList not populated
Customer not removed walletPaymentMeanDataList populated

You can update your information system with the new wallet content.

The "Wallet" service of the Sips Office interface allows the merchant to manage the wallet contents of his customers. The following features are available:

  • Obtaining the complete content of a subscriber account.
  • Obtaining details of a payment mean contained in a subscriber account.
  • Creating a new subscriber account.
  • Deleting a subscriber account.
  • Deleting a payment method from a subscriber account.

Using the Sips Office or Sips Office Batch interfaces, you need to manage the wallet management pages to allow your subscribers to manage their accounts.

Sips Office allows you to view customer details through a getWalletData request.

  • Setting the request
    To view the content of a wallet with the getWalletData method, you should populate the fields below:
    Field Value
    merchantWalletID Customer identifier

    Please refer to the Sips Office guide corresponding to the selected connector (JSON or SOAP) to learn how to populate the other fields for the request, depending on your business requirements.

  • Analysing the response
    Status Response fields Action to take
    Customer found in the wallet database

    walletReponseCode = 00

    walletPaymentMeanDataList filled with the payment methods recorded in the wallet

    The customer exists in the wallet.

    Analyse the walletPaymentMeanDataList field to access the customer payment method details
    • paymentMeanBrand
    • paymentMeanId
    • maskedPAN
    • PANExpiryDate
    Customer not found in the wallet database

    walletReponseCode = 25

    The account has been deleted or was not created.
    Other refusals

    walletReponseCode = xx

    Please refer to the Sips Office guide corresponding to the selected connector (JSON or SOAP) to analyse the WL Sips response.

Sips Office allows you to modify the alias of a customer payment method via the updatePaymentMean request.

  • Setting the request
    To modify a payment method via the updatePaymentMean request, you should populate the fields below:
    Field Value setting
    merchantWalletID Customer identifier
    paymentMeanId Sequence number of the payment method
    paymentMeanAlias New payment method alias

Please refer to the Sips Office guide corresponding to the selected connector (JSON or SOAP) to learn how to populate the other fields for the request, depending on your business requirements.

  • Analysing the response
Status Response fields Action to take
Alias modified

walletReponseCode = 00

walletActionDateTime populated

Customer not found in the wallet database

walletReponseCode = 25

The abonné account doesn't exist.
Other refusals

walletReponseCode = xx

Please refer to the Sips Office guide corresponding to the selected connector (JSON or SOAP) to analyse the WL Sips response.

Sips Office allows you to delete a customer via the signOff request.

  • Setting the request

To delete a wallet with the signOff method, you should populate the fields below:

Field Value setting
merchantWalletID Customer identifier

Please refer to the Sips Office guide corresponding the selected connector (JSON or SOAP) to learn how to populate the other fields for the request, depending on your business requirements.

  • Analysing the response
Status Response field Action to take
Customer deleted walletReponseCode = 00 You can update your information system.
Customer not deleted walletReponseCode = xx Please refer to the Sips Office guide corresponding to the selected connector (JSON or SOAP) to analyse the WL Sips response.

If the subscriber wishes to change his payment method (lost card, expired validity, ...), you must create a new wallet with a new subscriber ID to register the new payment details.

Attention: The renewal of a CB, VISA, MASTERCARD or AMEX card requires the creation of a new CIT which will be used as the basis for subsequent MITs. You must repeat the steps described in the section "enrolling the subscriber (CIT)".

On a monthly basis, you will receive by email or SFTP an expired cards report. This report references customers whose payment methods are due to expire in 3 months.

Based on this expired cards report, you can alert your customers to update the payment methods recorded in their wallets.

Please note that you won't need this file to know the expiry dates of your customers payment methods. Indeed, when a customer enrols, you will receive information in response that you can store in your information system:

  • ID for the payment method in the wallet (paymentMeanId field)
  • Payment method brand (paymentMeanBrand field)
  • Expiry date (panExpiryDate field)
  • Masked PAN (maskedPan field)

For details of the expired cards report content, please view the "Report Description" document.

Here is an example of subscription payment with a 1st payment within 6 days:


Example of a payment by subscription with a first payment due within 6 days

28 July 2021, day of the order (CIT) with authentication at 10 euros and authorisation at 10 euros. The duration of the authorisation request runs from 28 July to 3 August (6 days). On 2 August 2021, i.e. D+4, remittance of the first due date (CIT) with 3DS data. On 15 August 2021, i.e. D+34, triggering of the 2nd due date (MIT1) which leads to a chained authorisation request with the CIT and a remittance without 3DS data of 10 euros.

Connectors:

CIT MIT
Connector
  • Sips Paypage
  • Sips Office
  • Sips In-App
  • Sips Office
  • Sips Office Batch

Request parameters :

Field CIT MIT
paymentPattern RECURRING_1 RECURRING_N
ChallengeMode3DS CHALLENGE_MANDATE X
captureDay [ 0 , 6 ] [ 0 , 99 ]
captureMode
  • AUTHOR_CAPTURE
  • VALIDATION
  • AUTHOR_CAPTURE
  • VALIDATION
amount amount 1st due date amount nth due date
authentAmount Average amount of the due dates X
initialSchemeTransactionIdentifier X value of the schemeTransactionIdentifier field received in response from the CIT

Here is an example of subscription payments with a 1st payment more than 6 days away:


Example of a payment by subscription with a first payment due after 6 days

On July 28th 2021, day of the order (CIT) with authentication at 10 euros and an card information request triggered by an amount of EUR 0. The duration of the authorisation request runs from 28 July to 3 August (6 days). On August 5th 2021, i.e. D+8, triggering of the 1st due date (MIT1) which leads to a chained authorisation request with the CIT and a remittance without 3DS data of 10 euros. On August 15th 2021, i.e. D+34, triggering of the 2nd due date (MIT2) which leads to a chained authorisation request with the CIT and a remittance without 3DS data of 10 euros.

Connectors :

CIT MIT
Connector
  • Sips Paypage
  • Sips Office
  • Sips In-App
  • Sips Office
  • Sips Office Batch

Request parameters:

Field CIT MIT
paymentPattern RECURRING_1 RECURRING_N
ChallengeMode3DS CHALLENGE_MANDATE X
captureDay 0 [ 0 , 99 ]
captureMode X
  • AUTHOR_CAPTURE
  • VALIDATION
amount 0 amount nth payment
authentAmount average amount of the due dates X
initialSchemeTransactionIdentifier X Value of the field schemeTransactionIdentifier, received in the CIT response.

Your store has not been registered to WL Sips.

If your store is not yet registered, you should complete the registration form (requesting the subscription service) and return it to Worldline.

Your store is already registered to WL Sips.

If your store is already registered to WL Sips, you should ask Worldline to activate the subscription service.

Configuration data of the subscription service.

  • Interfaces used for enrollment
    • Sips Paypage
    • Sips Office
    • Sips Office Batch
  • Interfaces used for debiting or crediting subscribers
    • Sips Office
    • Sips Office Batch
  • If a subscriber database is shared between several stores of the same brand, please give the brand ID.
Note: if your subscriber database is shared between several stores, you should state this in the registration form or inform technical support.

If this is not specified, WL Sips will set up a wallet database for your store only.

When you have chosen the WL Sips interfaces that meet your needs (see section 3), you should integrate the Sips connectors to connect your site to WL Sips.

The previous section described how to use WL Sips within the framework of the subscription depending on the various connectors:

  • Name of methods
  • How to fill and analyse the subscription business fields

Please refer to the relevant connector guides to configure the payment requests based on your needs (customerID, orderId, returnContext, etc.)

Once the implementation of the WL Sips connectors is complete, you can run tests to validate your WL Sips integration.

Contact technical support and ask them to configure your store on the acceptance environment and the transfer of files if you use Sips Office Batch.

Test data
merchantId 201000076660001
secret key 8yTiAEzvhl7xt3_oEbdaH9Y9NY9A4XpNEjkk6q6Dou4
key version 1
test cards see "Test cards" page

Server Test URL
WalletPage POST https://payment-webinit.test.sips-services.com/walletManagementInit
WalletPage JSON https://payment-webinit.test.sips-services.com/rs-services/v2/walletManagementInit
WalletPage SOAP https://payment-webinit.test.sips-services.com/services/v2/walletManagementInit
Paypage POST https://payment-webinit.test.sips-services.com/paymentInit
Paypage JSON https://payment-webinit.test.sips-services.com/rs-services/v2/paymentInit
Paypage SOAP https://payment-webinit.test.sips-services.com/services/v2/paymentInit
Office https://office-server.test.sips-services.com
Attention:

the test webshop is configured in transactionReference mode, with no automated generation of the transactionReference. Therefore you need to send the populated transactionRefence in your test requests.

You can now validate the connection to WL Sips in production environment.

Prior to this, we recommend that you isolate your website from the public, to prevent customers from making transactions during this validation phase.

You should change the URL to connect to the production WL Sips server, using the IDs received during registration for the merchantId, secretKey and keyVersion.

URL WL Sips URL of the WL Sips payment server received by email.
MerchantId Shop ID received by email.
SecretKey Secret key that you get from the Sips Download extranet.
KeyVersion Version of the secret key retrieved from Sips Download (logically 1 for the 1st key).
Tip: a common mistake is to forget one of these four settings, which always causes an error.

If you want to customise your payment pages or wallet management pages, please follow the procedure described in the Custompages document.

Immediately

  • Submit an enrolment request based on the enrollment scenario that you have chosen.
  • Refer to the content of the wallet using the getWalletData of the Sips Office connector.
  • Resubmit the request with the same subscriber ID. Your enrollment should have been rejected owing to the fact that the wallet is based on a single payment method.

Immediately

  • Submit a walletOrder request to trigger a subscriber debit.
  • View the transaction via Sips Office Extranet BackOffice using the transactionReference or transactionId.

The next day

  • Check that the transaction appears in the transactions report
  • Check your business account to make sure that the operation has been credited
  • Refund the transaction via Sips Office Extranet BackOffice (optional).

Two days later

  • Check that the refund operation appears in the operations report.
  • Check the debit on your business account after the refund.

Immediately

  • Submit a walletCredit or WalletCreditHolder request to trigger a subscriber credit
  • View the transaction via Sips Office Extranet BackOffice using the transactionReference or transactionId.

The next day

  • Check that the transaction appears in the transactions report.
  • Check your account to make sure that the operation has been debited.

Once the transition in production environment has been validated, you can open your website to the public to enable your customers to use the service and to register.

During the day

  • Monitor acceptance rates (number of responseCode 00 per total number of transactions).
  • Check the nature of non-banking refusals.
    • Technical problem: responseCode 90, 97, 99
    • Fraud: responseCode 34, 3-D Failure
    • Maximum number of payment attempts reached: responseCode 75

The next day

  • Check that all transactions processed (accepted and refused) appear in the transactions report.
  • Check the operations you have made and remittances (if you have chosen this report option) in the operations report.
When you submit your first subscriber debits via Sips Office Batch or Sips Office:
  • Monitor acceptance rates (number of responseCode 00 per total number of transactions).
  • Check the nature of non-banking declines.
    • Technical problem: responseCode 90, 97, 99
    • Acquirer fraud: responseCode 34

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