Introduction
Mercanet 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.
Who does this document target
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 Mercanet solution.
To get an overview of the Mercanet solution, we advise you to consult the following documents:
- Functional presentation
- Functionality set-up guide
Prerequisites
Subscription payments require your subscribers' payment details to be stored by Mercanet 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 Mercanet 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.).
Subscription service overview
Functional description
Subscriber details Storage
When you record a subscriber in your information system, you should allocate a unique account ID that Mercanet 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:
You manage the subscriber's ID, which is associated to your customer's account. Mercanet 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, Mercanet stores the mandate ID in the wallet database.
The subscription service is based on the Mercanet wallet, a secure virtual wallet, where the subscriber's payment details are stored:
- The wallet is a single payment method.
- Subscriber ID =
merchantWalletId
.
The payment methods compatible with recurring payments are:
- Carte CB, Visa, Mastercard, Amex, Bancontact (WIP feature required)
- Mandat SDD (SEPA Direct Debit).
Mercanet 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
However, Mercanet allows the same wallet database to be shared among several webshops of the same brand.
If this applies to you, please contact technical support.
Subscriber enrollment (CIT)
The subscriber enrollment involves recording subscriber payment details in the Mercanet wallet. The enrollment may or may not be associated with a first payment.
Subscribers can be enrolled via 2 interfaces:
- Paypage: you save the subscriber's payment details when the first payment is made from pages hosted by Mercanet.
- Office (M2M) M2M: you manage your own pages for entering payment details and you use the online web interface to record the subscriber in the Mercanet wallet.
Subscriber due dates payments (MIT)
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:
- Office (M2M) M2M: you connect to Mercanet via an online web interface for transmitting debit or credit requests.
- Office Batch: on each due date, you transfer a file to Mercanet containing the debit or credit requests of the subscribers.
Subscriber management
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
Subscriber authentication
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 Mercanet 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.
Mercanet manages the secure storage of subscriber payment details.
Pages customisation
To maintain the corporate identity of your e-commerce website, the Paypage and Walletpage interfaces can be customised.
Please view the Page Customisation Guide for more information.
Reporting
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.
Data to be retained for chaining CIT MIT
In order to process the next subscription due dates (MIT) and to be
able to link them to the CIT, please keep the merchantWalletId
.
Choice of Mercanet connectors for subscriptions
Given that Mercanet 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 | Paypage | Office (M2M) | In-App | Office Batch | Walletpage | Mercanet Back Office 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 Paypage to process your payments, you can take advantage of this existing integration to manage your subscriber enrollment. Otherwise use the 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 | Office (M2M) meets your e-commerce requirements. For m-commerce, we encourage the use of 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 Office Batch file mode is the connector used for the periodic batch processing of subscriber payments, but you could use Office (M2M) 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 Office (M2M) 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 Office (M2M) if you want the option to delete in real time and Office Batch if you do not. If you do not want to automate this function, you can delete your subscribers from the BackOffice Mercanet. |
Initialisation of the subscriber database | |||||||
You migrate an existing database. | X | X | X | V | X | X | Office Batch allows you to initialise the subscriber database from an existing database. |
Implementation
To implement Mercanet subscriptions, you should get a suitable Connector Guide.
Enrolling the subscriber (CIT)
Enrolling the subscriber with Paypage
This is a typical Paypage payment process, where the payment details are recorded in the wallet if the transaction is accepted.
Description
- To record the subscribers' payment details, you should redirect them to Paypage, sending the transaction data in the request (amount, currency, etc.), as well as the subscriber ID (merchantWalletId field).
- Mercanet displays the payment page, the subscriber provides their payment details, then confirms.
- Mercanet makes a 3-D Secure verification.
- Mercanet makes anti-fraud checks.
- Mercanet sends an authorisation request to the Acquirer.
- Mercanet records the transaction in the back office.
- If the transaction is approved Mercanet records the subscriber payment details in the wallet.
- Mercanet displays the payment receipt page with a confirmation message that the subscriber payment method has been registered.
- Mercanet returns the manual and automatic responses containing the transaction details, including the result of the subscriber registration in the wallet.
- Mercanet may or may not send the transaction for collection, depending on the parameters that you have configured in the payment request.
Setting the request
Make a classic payment 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) |
Analysing the response
Mercanet returns a typical 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 |
|
Store the following customer details in your subscriber database:
You can submit recurring payments. |
Transaction accepted Subscriber not enrolled |
|
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 Paypage Connector Guide to analyse the Mercanet response. |
Enrolling the subscriber with Office (M2M)
Before recording the payment method in the wallet, you should have to check it first via a standard payment request.
Description
You manage the data entry for payment methods on your website.
- Step 1: You send a request to Mercanet 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.).
- Mercanet records the transaction.
- Mercanet may or may not send the transaction for remittance to the acquirer, depending on the elements provided in the request.
- Mercanet sends you the results of the payment methods verification.
Step 2: Once the payment method has been verified, you send a second request to Mercanet to register the payment method in the wallet.
- Mercanet returns the payment method registration response.
The sequence described above applies to the Amex, and Bancontact means of payment.
Setting the payment method verification requests
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 |
Please refer to one of the Office (M2M) 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.
Analysing the authorisation response with anti-fraud checks
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. |
Setting the enrollment request for customer payment details
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 |
Please refer to the adequate Office (M2M) guide, as well as the Payment methods guides, to learn how to populate the request, depending on your business requirements.
Analysing the enrollment response
Status | Response fields | Action to be performed |
---|---|---|
Subscriber enrolled | paymentMeanId = 1 |
You can debit or credit your subscriber |
Subscriber not enrolled Invalid request |
|
Please refer to the Office (M2M) Connector Guide to analyse the Mercanet response |
Debiting a subscriber (MIT)
Debiting the subscriber with Office Batch
Once the subscriber is registered, you can debit him/her in offline mode with Office Batch.
Description
You format a 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.).
- You send the file to Sips via FTPS or SFTP.
- Mercanet retrieves the subscriber payment details stored in the wallet.
- Mercanet executes the anti-fraud checks that you configured for your store.
- Mercanet sends the authorisation requests to acquirers.
- Mercanet stores the transaction in the back office.
- Mercanet formats the response file and sends it to you.
- In the evening, Mercanet sends the payment collection of accepted transactions.
Please consult the Office Batch XML or Office Batch CSV guides to find out more about implementation (file structure, description of records, file transfer, error management etc.).
Setting the request
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 Office Batch XML or 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 |
Analysing the response
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 Office Batch Connector Guide to analyse the Mercanet response. |
Debiting the subscriber with Office (M2M)
The Office (M2M) 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 Office (M2M) to find out more about the implementation.
Crediting the subscriber
Crediting the subscriber withOffice Batch
You can credit a subscriber based on their ID without reference to an initial debit transaction.
Description
The Office Batch solution allows batch payments to be made.
You format a 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.).
- You send the file to Mercanet via FTPS or SFTP.
- Mercanet retrieves the subscriber payment details stored in the wallet.
- Mercanet sends the authorisation requests to acquirers.
- Mercanet stores the transaction in the back office.
- Mercanet formats the response file and sends it to you.
- In the evening, Mercanet sends the payment collection of accepted transactions.
Please consult the Office Batch XML or Office Batch CSV guides to find out more about implementation (file structure, description of records, file transfer, error management etc.).
Setting the request
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 Office Batch XML Office Batch CSV guides to learn how to complete the other fields for the request, depending on your professional requirements.
Analysing the response
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 Office Batch Connector Guide to analyse the Mercanet response |
Crediting the subscriber Office (M2M)
The Office (M2M)JSON/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 Office Batch.
Please refer to Office (M2M) to find out more about the implementation.
Managing a customer's payment methods and account
With Walletpage
Description
The 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
Setting the request
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 Walletpage guide corresponding to the selected connector (JSON, POST or SOAP) to learn how to populate the request, depending on your business requirements.
Analysing the response
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. |
With Office (M2M) and Office Batch
Overview
The "Wallet" service of the Office (M2M) 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 Office (M2M) or Office Batch interfaces, you need to manage the wallet management pages to allow your subscribers to manage their accounts.
Viewing the content of an OneClick account with Office (M2M)
Office (M2M) allows you to view customer details through a getWalletData request.
- Setting the requestTo 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 Office (M2M) 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 Office (M2M) guide corresponding to the selected connector (JSON or SOAP) to analyse the Mercanet response.
Modifying the alias of payment method of an OneClick account with Office (M2M)
Office (M2M) allows you to modify the alias of a customer payment method via the updatePaymentMean request.
- Setting the requestTo 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 Office (M2M) 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 Office (M2M) guide corresponding to the selected connector (JSON or SOAP) to analyse the Mercanet response. |
Deleting a customer with Office (M2M)
Office (M2M) 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 Office (M2M) 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 Office (M2M) guide corresponding to the selected connector (JSON or SOAP) to analyse the Mercanet response. |
Modifying the subscriber payment method
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.
Anticipating the customers payment methods expiry
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.
Summary
Subscription payment with 1st payment within 6 days
Here is an example of subscription payment with a 1st payment within 6 days:
Connectors:
CIT | MIT | |
---|---|---|
Connector |
|
|
Request parameters :
Field | CIT | MIT |
---|---|---|
paymentPattern |
RECURRING_1 | RECURRING_N |
ChallengeMode3DS |
CHALLENGE_MANDATE | X |
captureDay |
[ 0 , 6 ] | [ 0 , 99 ] |
captureMode |
|
|
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 |
Subscription payments with 1st payment more than 6 days away
Here is an example of subscription payments with a 1st payment more than 6 days away:
Connectors :
CIT | MIT | |
---|---|---|
Connector |
|
|
Request parameters:
Field | CIT | MIT |
---|---|---|
paymentPattern |
RECURRING_1 | RECURRING_N |
ChallengeMode3DS |
CHALLENGE_MANDATE | X |
captureDay |
0 | [ 0 , 99 ] |
captureMode |
X |
|
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. |
5 steps to getting started with Subscription
Step 1 - Subscribing to the service
Your store has not been registered to Mercanet.
If your store is not yet registered, you should complete the registration form (requesting the subscription service) and return it to BNP Paribas.
Your store is already registered to Mercanet.
If your store is already registered to Mercanet, you should ask BNP Paribas to activate the subscription service.
Configuration data of the subscription service.
- Interfaces used for enrollment
- Paypage
- Office (M2M)
- Office Batch
- Interfaces used for debiting or crediting subscribers
- Office (M2M)
- Office Batch
- If a subscriber database is shared between several stores of the same brand, please give the brand ID.
If this is not specified, Mercanet will set up a wallet database for your store only.
Step 2 - Implementing the service
When you have chosen the Mercanet interfaces that meet your needs (see section 3), you should integrate the Sips connectors to connect your site to Mercanet.
The previous section described how to use Mercanet 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.)
Step 3 - Testing the service in the acceptance environment
Once the implementation of the Mercanet connectors is complete, you can run tests to validate your Mercanet integration.
Contact technical support and ask them to configure your store on the acceptance environment and the transfer of files if you use 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.mercanet.test.sips-services.com/walletManagementInit |
WalletPage JSON | https://payment-web-mercanet.test.sips-services.com/rs-services/v2/walletManagementInit |
WalletPage SOAP | https://payment-web-mercanet.test.sips-services.com/services/v2/walletManagementInit |
Paypage POST | https://payment-web-mercanet.test.sips-services.com/paymentInit |
Paypage JSON | https://payment-web-mercanet.test.sips-services.com/rs-services/v2/paymentInit |
Paypage SOAP | https://payment-web-mercanet.test.sips-services.com/services/v2/paymentInit |
Office | https://office-server-mercanet.test.sips-services.com/ |
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.
Step 4 Validating the service in production environment
You can now validate the connection to Mercanet 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 Mercanet server, using the IDs received during registration for the merchantId, secretKey and keyVersion.
URL Mercanet | URL of the Mercanet payment server received by email. |
MerchantId | Shop ID received by email. |
SecretKey | Secret key that you get from the Mercanet Téléchargement extranet. |
KeyVersion | Version of the secret key retrieved from Mercanet Téléchargement (logically 1 for the 1st key). |
If you want to customise your payment pages or wallet management pages, please follow the procedure described in the Custompages document.
How to validate enrollment
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 Office (M2M) 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.
How to validate subscriber debit
Immediately
- Submit a walletOrder request to trigger a subscriber debit.
- View the transaction via Mercanet Back Office 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 Mercanet Back Office 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.
How to validate subscriber credit
Immediately
- Submit a walletCredit or WalletCreditHolder request to trigger a subscriber credit
- View the transaction via Mercanet Back Office 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.
Step 5 - Launching the service in production environment
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.
Customer enrollment
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.
Subscriber debit
- 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