Payments
Central element in our service, a payment represents a payment transaction, between your end customer and you, with Stancer as intermediary. It must contain an amount. Once the payment has been made, it can also contain a means of payment, as well as a customer. A payment can be made via API or via TPE, and differences apply. For example, a refund can only be made via API on payments made directly by API.
This section details the payment methods provided by Stancer and how to manage them for your business activity.
Choose your means of payment
Which means of payment should you offer your customers?
The choice of the means of payment you accept for the payment of customer purchases in your establishment is a key factor for the success of your business. We have thus written this section to help you understand and choose the means of payment to which you direct your customers.
With our solutions, two main types of payments are possible for your customers.
- One-off payments: a single payment for a product or service
- Recurring payments: the payment of the product and/or service is repeated, with the same amount, at fixed intervals that are determined by the merchant.
Stancer gives you the possibility of selecting the payment methods you prefer for your business activity when you integrate our API directly. Please consult the Technical Documentation to learn more about this functionality.
This table summarises the different types of payments that are accepted by Stancer’s services:
| Stancer solution | One-off payments | Recurring payments |
|---|---|---|
| Terminal | Payment Cards | |
| API | Payment Cards, SCT, SCT Inst | Recurring Card Payments, SDD |
| Shop | Payment Cards, SCT, SCT Inst | Recurring Card Payments, SDD |
One-off payments
These are single payments for a product or service.
Payment cards (PC)
This is one of the most popular means of payment in Europe. Payment cards are marketed and distributed by card issuers, such as banks. Payment cards use Card Schemes such as Visa or Mastercard in order to function. They provide a purchasing experience that is now very familiar to your customers and one that is secure. Stancer provides transparent billing for the acquisition of payment cards that use the Carte Bleue, Visa and Mastercard Card Schemes.
Flow
Scope
The various Card Schemes make it possible to use a payment card almost anywhere in the world. Stancer services are compatible with the following Card Schemes: Carte Bleue, Visa and Mastercard.
Specific pre-requisites
- For the Stancer API: integration of the API.
- For the Stancer terminal: the payment terminal must be turned on.
Focal points
In response to the widespread (and increasing) use of payment cards, the technical community has developed security protocols for online transactions, in order to limit the cases of fraud associated with this means of payment. For example, the 3DS and 3DS V2 protocols will enable you to protect yourself against attempted fraud.
Contactless payment
For card-present transactions at the point of sale, contactless payment makes it possible for the cardholder to pay for their purchase without entering their PIN. The Stancer terminal provided to you is compatible with contactless payment. This functionality is activated as soon as the terminal is received: you do not need to take any action.
To make a contactless payment, the cardholder places their payment card near to the payment terminal. The transaction is then processed without entering the PIN. Please note that the payment card issuer (i.e., your customer’s bank) may limit the number of contactless transactions that are authorised each day. Contactless payment may then be rejected and your customer will have to make a standard payment by inserting their payment card into the Stancer terminal.
Fees
The fees for card payments depend on the Card Scheme for your customer’s card (see the Pricing & Fees).
SEPA Credit Transfert (SCT)
Payment by SCT involves your customer sending the funds needed to pay for their purchase to your Stancer account.
From a practical standpoint, when selecting the option for payment by SCT, Stancer will provide your customer with the IBAN for your Stancer account to which the funds must be sent, as well as the transaction amount. The API will also generate a unique reference for the transaction, which your customer must enter. You can thus monitor the execution of your customer’s transfer and initiate the delivery of their order by means of this unique reference.
SCTs have the advantage of a fixed cost for acceptance, but have met with varying degrees of success within the SEPA.
Flow
Scope
SCT is available throughout the SEPA.
Pre-requisites
Your customer must have the IBAN for your Stancer account.
Focal points
- An SCT is generally executed within 24 hours; however, this timeframe may vary, depending on your customer’s bank, the time at which it is initiated and interbank payments.
- In order to be able to identify the order/service concerned by your customer’s payment, we recommend entering a unique reference in one of the information fields of the SCT.
- This method of payment is based on your customer initiating payment from their personal bank account dashboard. Your customer must therefore have the possibility of connecting to that dashboard in order to initiate the SCT.
Fees
The fees for processing an SCT are explained in our Pricing & Fees.
Instant transfer (SCT Inst)
Since 2019, the SEPA gives merchants who operate therein the possibility of being paid by SCT Inst. Payment by SCT Inst is similar to payment by SCT. This involves your customer sending the funds needed to pay for their purchase to your Stancer account. The difference lies in the time needed to execute the transaction: payment by SCT Inst takes less than eight seconds, compared to 24 hours for an SCT.
SCT Inst therefore has benefits for your business activity:
- The instant nature of the transfer: the funds are available almost immediately.
- The low cost of the transfer: like the SCT, the SCT Inst has the advantage of a fixed cost for the merchant, regardless of the amount of the transaction.
- The transfer is irrevocable: your customer cannot dispute their payment if it is made via an SCT Inst.
Flow
The flow for an instant payment has the same stages as an SCT. The major difference lies in the transaction execution time. This time is reduced to eight seconds for an SCT Inst, compared to 24 hours on average for a standard SCT.
Scope
This means of payment is available throughout the SEPA.
Pre-requisites
- All of the specific pre-requisites for the SCT.
- Your customer may have to activate the SCT Inst option on their bank account dashboard in order to be able to pay you using this means.
Focal points
- The amount of an SCT Inst is limited to €100,000.
- The SCT Inst is based on your customer initiating payment from their personal bank account dashboard. Your customer must therefore have the possibility of connecting to that dashboard in order to initiate the SCT Inst.
- In order to be able to identify the order/service concerned by your customer’s payment, we recommend entering a unique reference in one of the information fields of the SCT Inst.
Fees
The fee for processing an SCT Inst is specified in our Pricing & Fees.
Recurring payments
These are repeated payments that use the same means of payment. The amount and the frequency of these payments are parameters that you can define. These payments are particularly appropriate for merchants who offer a subscription to a service or payment in instalments.
SEPA Direct Debit (SDD)
This payment method involves debiting your customer’s bank account for a pre-determined amount. Within the SEPA, SDDs are a secure means for your customers to purchase a subscription from you.
Flow
Scope
SDD is available throughout the SEPA.
Pre-requisites
- Your customer’s IBAN.
- Your SEPA Creditor Identifier (SCI): this is a unique identifier that enables all the banking parties to identify your company before debiting your customer’s account.
- The signature of a valid direct debit mandate (SEPA direct debit mandate) by your customer and the unique reference for that mandate (Unique Mandate Reference - UMR).
Management of mandates
Accepting payments via SDD involves managing the direct debit mandates that are necessary in order for them to be processed correctly.
You are responsible for the validity of the mandates that are signed with your customers. In this capacity, you must respect the formal requirements of direct debit mandates so that they are valid and accepted by your customers’ banks.
For the record, SEPA direct debit mandates must contain certain information in order to be valid.
- the title “SEPA Direct Debit Mandate”.
- the Unique Mandate Reference (“UMR”).
- your contact details: address, name or corporate name (or the business or trading name, if this is different).
- your SEPA Creditor Identifier (SCI).
- The following wording: By signing this mandate form, you authorise (A) {your name} to send instructions to your bank to debit your account, and (B) your bank to debit your account in accordance with the instructions from {your name}. As part of your rights, you are entitled to a refund from your bank under the terms and conditions of your agreement with your bank. A refund must be claimed within eight weeks starting from the date on which your account was debited.
All of the necessary information is specified by the Banque de France.
Rejected SDDs
Direct debits may fail for several reasons: insolvency, closure of your customer’s account, cancellation of the direct debit mandate, etc.
You can identify the reason for rejections:
- on the Payment page of your Client Dashboard,
- via the API response codes explained in the Technical Documentation.
You can then attempt another direct debit as soon as you wish or propose that your customer use another means of payment. Please note that specific fees apply in the event of a rejected direct debit. They are explained in the Pricing & Fees. These specific fees result from the charges that the banking networks apply to Stancer.
Fees
The rate is specified in our Pricing & Fees.
FAQ
How can I reduce my direct debit failure rate? The percentages of rejected/disputed direct debits can be reduced through improved communication with your customers concerning the invoicing of your goods and/or services.
I do not have an SCI: how can I obtain one? Stancer can help you to obtain your SCI. Make a request on the Support page of your Client Dashboard, and our teams will take the appropriate steps for you.
Recurring card payments
A recurring card payment involves using your customer’s card to make a recurring payment. Recurring card payments rely on Card-on-File Tokenization: Stancer places the payment card on file securely, in the form of a token that is provided to you. The tokenization of your customers’ cards on file means you can make requests for direct debits from the associated bank accounts for as long as the cards are valid. All you have to do is to notify this token to our API for the subsequent payments.
Flow
The flow for a recurring card payment is as follows:
- When the first payment is made, your customer enters their card details. The Stancer API will then create a token which is associated with that card.
- Next, the Stancer API will provide you with this token.
- For subsequent payments, you will need to submit this token in order to initiate a payment using the same card.
- Stancer will then check the validity of the card and execute the payment.
Initial payment
Recurring payments
Scope
The scope of recurring card payments is the same as for one-off card payments.
Pre-requisites
Initial payment: the recurring card payment requires a token to be created that you can then submit to Stancer in order to attempt a new debit on your customer’s account. The first payment, which will initiate the recurring payments on your customer’s card, must therefore be entered in a specific field in our Documentation labelled “tokenize”.
Subsequent payments: after the token associated with the card is created, all you have to do for subsequent payments is to make a request to our API using that token. You must also state the amount of the payment associated with this new debit.
Focal points
One of the main focal points concerning recurring card payments is the expiration of the card that is associated with the payments: when the card expires, it is impossible for us, at present, to continue the direct debits using the new card provided by your customer’s bank.
Therefore, the Stancer API will notify you when the expiration of a card on file is imminent. This will enable you to anticipate the expiration of the card that was originally tokenized and to contact your customer to ask them to update their means of payment on your website.
Fees
For each payment recurrence, the fee stated in our Pricing & Fees will apply (other than in specific cases, in particular rejections or disputes, which are also stated in our Pricing & Fees).
FAQ
What happens when there is a payment refusal/failure? The Stancer API will inform you of the outcome of each payment using the response codes that are explained in the technical documentation. In order to understand this code, you can consult our API directly. You can also consult the outcome of the payment by searching for the payment identifier in your Client Dashboard. It is then up to you to decide on the commercial course of action to be taken, depending on the reason for the payment failure. You can ask your customer to make another payment attempt or wait for the customer to reattempt to pay you.
How can I choose the payment methods I will accept from my customers? Using the Stancer API, you have the possibility of choosing the payment methods you will accept from your customers and of choosing the means of payment that are most suitable for your business activity.
Fraud mitigation
The security of your business activity is our priority. We have written this section to help you use and implement our risk management tools.
To address the risks of fraud for your establishment, Stancer has set up two-level protection:
- Your Level: The personalised parametrization of the means of payment accepted and the triggering of strong authentication (which can be parameterized).
- At the level of Stancer and its partners: real-time analysis of the data linked to the transaction on the basis of our algorithms enables us to protect you from payments that appear to have a high probability of fraud.
These two layers of protection enable you to prevent attempted fraud while retaining your conversion rate.
Strong authentication (3DS)
Strong authentication is a mechanism for securing card-based payments. It is designed to authenticate the holder of a payment card by a second authentication factor that is supported by their bank (Confidential Code, SMS, Biometrics, etc.). The term “3DS” refers to the implementation of the strong authentication mechanism by Card Schemes such as Visa or Mastercard.
There have been two successive versions of 3DS:
- 3DS V1: the cardholder authenticated their identity using a confidential code. This code, depending on the issuing banks, can be constant or generated randomly at the time of the transaction. It is sent by the issuing bank to the cardholder, often by means of an SMS, when the payment is executed. The cardholder then enters their code on the 3DS page in order to confirm the payment.
- 3DS V2: in addition to authentication by means of the confidential code as in V1, it is also possible using biometric data (e.g. a fingerprint or facial recognition). This mechanism provides additional security for the payment.
Within the EU, there is a regulatory obligation for banking institutions to use the 3DS V2 protocol in order to authenticate cardholders. Stancer’s solutions are compatible with 3DS V1 and V2. You can thus securely authenticate your customers when they make their payments.
Advantages of 3DS
Strong authentication with 3DS has two major advantages for your business activity:
- Fewer cases of fraud: using 3DS enables you to verify the identity of your customer, and thus reduce the risk of fraud. Use of 3DS is completely free of charge and does not incur any fees for you or your customer. It is therefore an efficient and tested means of combatting attempted payment card fraud.
- Reduced costs associated with fraud: triggering 3DS shifts the liability in the event of established fraud: your customer’s bank will then be liable for the payment. Thus, all fraud associated with the transaction would be the responsibility of your customer’s bank.
Implementing 3DS
Through our experience and the volumes of transactions we process, we have the appropriate parameters for triggering strong customer authentication. These generic parameters protect you against the vast majority of attempted fraud.
Generic 3DS parameters are implemented automatically: no actions or updates are required from you.
In addition to these generic parameters, Stancer enables you to parameterize when 3DS is triggered, according to your preferences and the constraints associated with your business activity. We recommend that you pay particular attention to this parametrization and continually monitor its implementation. Indeed, 3DS is at the heart of your protection against attempted fraud. In practice, we encourage you to give priority to the security of your activity at all times over the improvement of your conversion rate.
The following are included in the parameters for triggering 3DS:
- The transaction amount,
- The date and time of the transaction,
- The geographical origin of your customer (parameter based on the connection information provided by the customer),
- The digital “fingerprint” of the transaction: the browser used, the browser language and the device used,
- The Bank Identifier Code (BIC).
Triggering the 3DS mechanism
This table summarises the various methods for triggering 3DS, according to the integration method of our API:
| Integration method | Triggering of 3DS |
|---|---|
| Full API | Technical Documentation |
| iFrame | Technical Documentation |
| Hosted | Triggered automatically |
| Redirect | Triggered automatically |
3DS and conversion
Use of 3DS may cause friction in the purchasing experience and potentially affect your conversion rate. For example, your customer’s bank may encounter technical difficulties that prevent 3DS from being triggered. This means in practice that the 3DS fails, without Stancer being able to correct it. Particular attention should therefore be paid to the rules and mechanisms for triggering 3DS, in order to protect you against attempted fraud while maintaining your conversion rate.
Frictionless authentication
Using the 3DS V2 protocol, it is now possible to use strong authentication that facilitates conversion: frictionless authentication. Frictionless authentication occurs when the parties in the payment chain deem the risk of fraud to be sufficiently low in light of in-house technical and operating rules. They then authorise the authentication of your customer without the customer having to undergo “active” strong authentication (biometrics or entering a confidential code).
With frictionless authentication, you benefit from all the guarantees afforded by strong authentication, without it intervening in your customer’s purchase process.
3DS with the Stancer Terminal
Since the implementation of the European PSD2 directive, the strong authentication mechanism may be triggered when a card-present payment is made. Your customer’s bank may conclude, on the basis of its own specific criteria, that a transaction is perhaps fraudulent (the amount is abnormally high, for example). As a result, your customer’s bank may trigger 3DS and ask your customer to authenticate their identity in order to confirm the transaction.
Similarly, your customer’s bank may decide that the number of contactless transactions authorised for the card has been attained. In this case, it may require a standard card-present payment with entry of the card PIN.
These requests for identification of your customer by the bank are normal and automatic. They make it possible to counter attempted fraud.
Payment in foreign currencies
Your business activities involve payments in foreign currencies if your customers are located outside of the euro zone and if you wish to give them the possibility of paying you in their national currency.
Currencies accepted
We provide payment services in the following currencies: GBP, USD, CAD and AUD.
Flow
The transaction is effected in the foreign currency for your final customer. We then pay out the converted amount in EUR to your Bank Account.
Minimum amounts
Minimum transaction amounts
In order to avoid the fees that are charged for a payment transaction (by Card, Transfer and/or Direct Debit) representing too high a proportion compared to the amount of the transaction concerned, the execution of payment transactions (by Card, Transfers and/or Direct Debits), the amount of which is less than a stipulated minimum, are automatically refused.
This table presents the list of the minimum amounts for the various currencies accepted by Stancer:
| Currency | Minimum amount |
|---|---|
| EUR | 0.50 |
Modify the minimum amounts
To change the minimum transaction amounts, go to your Client Dashboard and send a message to our Support team, stating the desired amount and the currency concerned.
Payment status
The following table lists the different statuses of payments within the Client Dashboard:
| State | Description | Comments |
|---|---|---|
| Awaiting payment | Pending payment from your customer | |
| Authorized | The payment has been authorised by your customer's bank but the money has not yet been debited | |
| The payment has been cancelled before it is executed | ||
| Paid | The payment has been processed correctly: you will soon receive the funds in an outpayment | |
| Payment authorisation request has expired after 7 days | CB and CBR payments only | Failed payment |
| The payment has failed due to a technical error. | ||
| The payment has been disputed by the Payer | Find this payment in the My Disputes section to process the dispute, where possible | |
| Refused | The payer's bank has refused to execute the payment |
You will find more information about the status of your payment in its detailed record. The table below shows the detailed statuses in the payment record :
| State | Description | Comments |
|---|---|---|
| Not specified | Payment status cannot be determined at this time | |
| Authorized | The Payer's bank has authorised the payment to be executed, it will be executed when the capture argument is set to true. | Card and recurring card payments only |
| To capture | The Payer's bank has authorised the execution of the payment, it will be executed during the day | |
| Capture sent | Payment is being executed | |
| Captured | The payment has been executed correctly, you will receive the funds shortly in a payout | |
| Cancelled | Payment was cancelled | |
| Expired | Payment (authorisation request) expired after 7 days | Card and recurring card payments only |
| Failed | Payment failed due to a technical error | |
| Disputed | Payment was disputed | Retrieve the payment within 'My disputes' section to investigate the dispute |
| Refused | The Payer's bank refused to execute the payment |
Glossary
Our teams endeavour to explain the main terms and concepts associated with card-based payments, so that you have a better understanding of our activity.
- 3D Secure (3DS) :
The term 3D Secure is the primary implementation of the SCA mechanism by the Card Schemes. It reflects the pre-requisites of the SCA mechanism from a technical standpoint and is now widely used by the Card Schemes. In addition to its qualities in terms of security, the 3D Secure mechanism transfers your liability in the event of fraud: the bank that issued the card becomes liable in the event of established fraud involving the transaction concerned. This means that the bank in question will have to refund your customer if fraud is confirmed involving the card that was used for the payment.
- ACPR (French Prudential Supervision and Resolution Authority) :
Under the responsibility of the Banque de France, the ACPR’s role is to oversee all the operators in the world of finance and insurance in France. The ACPR issues the mandatory accreditations for Payment Institutions such as Stancer.
- Acquirer/Acquisition:
Payment acquisition means the transfer to the banking institutions of all the information that is necessary in order to process a transaction. Stancer thus carries out the acquisition of your payments.
- API (Application Programming Interface) :
XXXX
- Strong Authentication (also known as 3DS or Strong Customer Authentication (SCA)):
This mechanism is designed to make payments secure. It enables the payer to confirm their identity via a second authentication factor (e.g. SMS or confidential code). This mechanism was recently revised (version 2 has now been implemented) by the European revised Payment Services Directive (PSD2). Biometrics can now be used for this authentication (fingerprints, for example). Please note that the SCA mechanism is based on legislation: its technical implementation is reflected in the appearance of a term that is now closely associated with SCA: 3D Secure.
- BIC (Bank Identifier Code) :
This is the acronym for a bank’s international identifier code. It makes up the first characters (8 or 11) of an IBAN.
- BIN or IIN (Bank Identification Number ou Issuer Identification Number) :
This acronym designates the financial organisation that marketed a payment card. It can be found on the reverse of payment cards. Depending on the Card Schemes, it is the first four or five figures of the card primary account number ( PAN).
- Clearing house :
A clearing house is an organisation that enables financial operators to exchange their transfer orders by means of the clearing mechanism. The clearing house reconciles the exchanges to be made between the operators (banks) and transfers the net balances between them (known as netting). These platforms are used for SEPA payments (SDDs and SCTs). In France, the most well-known clearing house is the Core system operated by STET.
- Card Data :
PAN, CVV, CVC, etc. These acronyms refer to the means of identification for payment cards that are present on the cards themselves. The diagram above shows where these are located on the majority of payment cards.
- PSD2 (revised Payment Services Directive):
This European Directive, which was adopted on 8 October 2015, aimed to revise the European directives concerning payments made in the European Economic Area. PSD2 contains a set of new obligations for payment operators: merchants, financial institutions and regulators. These new provisions include version 2 of the SCA, which has a significant impact on merchants, as the SCA mechanism (and thus its 3DS implementation) must be triggered automatically. The complete text is available here.
- EMV (Europay Mastercard Visa) :
This is a standard for payment cards with which equipment intended to effect transactions on these Card Schemes must comply. The Stancer Terminal is EMV-certified.
- IBAN (International Bank Account Number) :
This is the identifier that enables any financial organisation to identify a bank account. This is a standard European/international format. In France the acronym “RIB” is still used to refer to bank account details. Nevertheless, each RIB is associated with an IBAN, which is used to effect all the transactions on the account. The nomenclature for IBAN meets international ISO standards: this means that Stancer can debit and credit accounts in numerous countries throughout the world.
- Interchange :
Interchange is a fee that is charged for a card-based payment. The cardholder’s (i.e., your customer’s) bank charges the bank that acquires the payment (i.e., Stancer’s bank) fees for debiting the account. This fee varies, depending on the Scheme, as well as on the type of card used for the payment. Various European regulations have been adopted in an attempt to reduce and/or remove interchange fees.
- Mandate :
In order to effect an SDD, the merchant must first have signed a mandate with their customer that authorises the merchant to debit sums from their bank account. Stancer uses this mandate to effect this direct debit and make the funds available to you. A mandate is identified by its UMR (Unique Mandate Reference). It is, in particular, with this identifier that you can ask Stancer to debit your customer.
- NFC (Near Field Communication) :
This is a contactless payment technology for all payment terminals. This term covers a set of hardware and software standards that ensure security of payments without the customer having to enter a PIN. Please note that the Stancer Terminal is compatible with this technology.
- PCI-DSS (Payment Card Industry Data Security Standard) :
PCI DSS is an IT security standard that certifies the computer resources used to store payment data (payment cards, for example). It was created by five payment card networks in 2006. This certification requires significant in-house security and process systems. Stancer’s compliance with this standard provides you and your customers with assurance that sensitive data is being stored securely. You may be asked to ensure PCI DSS compliance, depending on the method used to integrate our services (only API).
- PSP (Payment Service Provider) :
As the name suggests, this refers to a provider of payment services. As a Payment Institution (PI), Stancer is a PSP. The status of PI is a regulatory status that enables an undertaking to make payments on behalf of a third party (i.e., you). This status is regulated in France by the ACPR (French Prudential Supervision and Resolution Authority) and Payment Institutions must be accredited by the ACPR. Obtaining accreditation from the ACPR provides you with assurance of the security and reliability of our services.
- GDPR (General Data Protection Regulation) :
The General Data Protection Regulation is a European legislative document that regulates the processing of data, on an egalitarian basis, throughout the European Union. You have the possibility, at any time, of exercising your rights to said data using the forms provided by Stancer.
- Card Scheme :
This is a network of information exchange for payment cards. These networks make it possible to transmit transactions effected with the payment cards that use them. The most well-known Card Schemes are Carte Bleue, Visa, Mastercard and American Express.
- SCT (Sepa Credit Transfert) :
This acronym denotes a transfer effected within the SEPA.
- SDD (Sepa Direct Debit) :
This acronym denotes a direct debit effected within the SEPA.
- SEPA (Single Euro Payment Area) :
The Single Euro Payment Area (SEPA) corresponds to all the countries in which SDDs and SCTs are possible. The list of SEPA member countries is available here.
- Token :
A token is used to make information anonymous so that it can be designated and used without risk. For recurring card payments, Stancer tokenizes your customers’ payment cards so that they can be debited at a later date at no risk. Tokens must be stored by PSPs in the strictest compliance with PCI DSS standards: Stancer guarantees you the integrity and security of this data throughout the periods defined by the regulations.