Stancer documentation

English

Français
Italiano

English

Français
Italiano

Appearance

FAQ ​

Payment Flow ​

What is the recommended flow for an e-commerce integration?

The recommended flow is as follows:

  • Creation of a Payment Intent without immediate capture

  • Redirect the Payer to the payment page

  • The Payer completes the payment

  • Redirect back to your application

  • Validate the payment via the Stancer API, then capture the Payment Intent

This is the recommended flow for e-commerce payments. It allows you to verify the authorization success before capturing the funds definitively.

Redirect URL Management (return_url) ​

Does the return_url automatically identify the transaction?

No. The return_url does not directly transmit a transaction or Payment Intent identifier.

It is therefore recommended to manage a mapping on the Client side between:

  • Your order or cart identifier.

  • The Stancer Payment Intent identifier.

Example: https://your-webservice.com/return-url?order-id=XXXXXXXX

You can then retrieve the associated Payment Intent in your system.

If you initially create a Payment Intent without a return_url, you can also add this information later by modifying the Payment Intent.

Payment Intent Expiration ​

Does a Payment Intent expire automatically?

No. A Payment Intent does not have an automatic expiration period.

If necessary, you can delete an unpaid Payment Intent to cancel it.

Recurring Payments and Saved Cards ​

Are recurring payments supported?

Yes. Recurring payments are supported by the Stancer platform.

When a Customer makes a payment, a tokenized Card is automatically created and associated with the payment, regardless of the method used:

  • I-frame
  • Stancer payment page
  • Redirect
  • Custom integration.

Example:

sh
GET /v2/payment_intents/{id}

Response:

sh
{ 
  "id": "pi_xxxxx", 
  "card": "card_xxxxx" 
}

The card_xxx value corresponds to the identifier of the tokenized Card.

How can a saved Card be reused?

Once the Card has been tokenized, you must store the card_xxx identifier in your system. For a new payment, you can reuse this Card:

sh
POST /v2/payment_intents/

Response:

sh
{ 
  "amount": 1000, 
  "card": "card_xxxxx" 
}

In this case, no payment page is required: the transaction uses the tokenized Card directly.

Where should the subscription or recurring payment logic be managed?

The recurring payment logic must be managed on the Client side.

Example:

For a monthly subscription:

  • You store the card_xxx identifier
  • Each month, your system creates a new Payment Intent
  • The Payer is automatically charged.

This approach provides maximum flexibility:

Changing the payment date:

  • Amount change;
  • Frequency change;
  • Customization of payment information;
  • Management of specific cases.

Card Tokenization ​

Can a Card be saved without making an actual payment?

Yes. Tokenization is automatically performed when a payment is made. If you only want to save a Card without charging the Payer, you can create a Payment Intent with an amount of €0.

This allows you to:

  • Retrieve a tokenized Card
  • Capture the payment later if necessary.

This approach is recommended when you want to verify the bank authorization before actually charging the Payer.

Does the Payer see a difference between a standard payment and an authorization for future use?

No. For the end Payer, the flow is identical. The difference only concerns the technical management on the Client side and the information transmitted to the banks.

MIT / CIT: Payments Initiated by the Client ​

Can a payment be made with a saved Card without requesting a new validation from the Customer?

Yes. These payments correspond to MITs (Merchant Initiated Transactions). They are different from CITs (Customer Initiated Transactions), where the Customer directly initiates the payment. When a Card is used and tokenized, it can be reused to make future payments according to the applicable banking rules.

An update is planned to explicitly specify whether a payment is:

  • One-Time Only
  • Recurring Payment

This will make it easier to manage transaction chaining with banks.

Security and API Key Management ​

Should API calls be made from the backend?

Yes. Sensitive operations such as:

  • Payment creation
  • Refunds
  • Transaction management

must be performed from your backend using your private key. Your frontend must never expose this key. An attacker who obtains your private key could:

  • Create payments
  • Initiate refunds
  • View your transactions

The frontend must therefore call your backend, which then communicates with the Stancer APIs.

Does Card data pass through my infrastructure?

No. Card numbers must not pass through your infrastructure.

They are transmitted directly to Stancer in order to comply with PCI DSS security standards.

On your side, you only handle:

  • Tokenized card_xxx identifiers
  • Which are not sensitive data

Is there a frontend SDK to tokenize a Card on the Payer side?

Tokenization is automatic when a Card makes a payment. There is therefore no need to develop specific logic on the frontend. Sensitive data remains managed by Stancer.

Payout Management ​

Can Payouts be tested in a test environment?

No. Payout management is not available in the test environment. To validate the actual behavior of Payouts, it is recommended to move directly to production with small amounts.

Transaction Fees ​

How can I obtain the final amount of fees applied to a transaction?

The final fees are available via the API. They are only available once the transaction has reached the captured status. This status corresponds to the reference data used for billing.

Refund Management ​

What happens when a refund is made if the Stancer balance is 0 after a Payout?

If the Stancer balance is not sufficient to cover the refund:

  • A negative Payout is created
  • A direct debit is made from the Customer's Bank Account

Special case:

If a Payout is already pending, the refund amount is directly deducted from this Payout before it reaches your Bank Account.

Can a refund be cancelled?

No. Once a refund has been created, it cannot be cancelled.

Can a captured payment be refunded long after it was processed?

This mainly depends on the validity of the Card used. A refund may be declined if the Card has been expired for too long. The final decision depends on the issuing bank. In practice, refunds generally go through several months after expiration, but this becomes progressively more uncertain.

How can I retrieve the fees associated with a refund?

At present, refund-related fees are not exposed via the API. They remain visible in the Stancer User Area. An update is planned to make this information available via the API.

Payment Statuses and History ​

Why can a payment be displayed as "Paid" and then "Cancelled"?

A payment can have several statuses depending on the element being observed.

Example:

The payment was captured → status "Paid";

It was then refunded → status "Cancelled".

This distinction can cause confusion in the interface.

An improvement is planned to better distinguish:

  • Payment completed
  • Payment refunded
  • Payment cancelled before capture

Payment Intent and Synchronization ​

Does a Payment Intent waiting for payment expire automatically?

No. A Payment Intent remains active without any automatic time limit. It is not automatically cancelled after a given period.

Are there webhooks to track status changes?

Webhooks are currently evolving. Ultimately, they will make it easier to synchronize your systems with Stancer events. In the meantime, synchronization via periodic API calls remains possible.

Captures and Cancellations ​

What is the difference between a cancellation ‘before capture’ and a ‘refund’?

A payment cancelled ‘before capture’ does not result in any movement of funds. A ‘refund’ applies to a payment that has already been captured.

Emails Sent by Stancer ​

What emails are automatically sent by Stancer?

Stancer can send:

  • Receipts if this option is enabled
  • Refund emails when the refund is made from the Stancer User Area and the Customer has configured this option.

When a refund is made via the API, no automatic email is sent to the end Payer.

Can the emails sent be disabled or customized?

No. It is currently not possible:

  • To choose exactly which emails are sent;
  • To modify their content.

Why does the message say "you will be refunded in the next few days" when the payment was not captured?

This message can be misleading in the case of a cancellation before capture.

In this situation:

  • No financial transaction takes place
  • No bank refund is made

An update is planned to clearly distinguish "Cancellation" and "Refund"

Can the same order number be used multiple times?

Yes. The order number is only used as a business identifier to find a payment. It does not guarantee transaction uniqueness. It is therefore possible to have multiple payments with the same order number, both in test and production.

Why can a payment link be displayed in another language?

The language of the payment link depends on the language of the User Area. You can force the language using a parameter:

  • French: ?lang=fr
  • English: ?lang=en
  • Italian: ?lang=it

Example: https://your-payment-link.com?lang=fr

I-frame Interface and Card Network Selection ​

Why ask the Payer to choose their Card network when it is detected automatically?

Card network selection must remain available to the Payer in accordance with GIE Carte Bancaire directives.

The network can be detected automatically using the Card number, but the Payer must be able to choose their network.

If the selected option is not compatible:

  • Stancer automatically attempts the other available networks
  • The payment remains functional

The user's selection therefore does not prevent the payment from being completed.

Fee Calculation ​

How are fees calculated for a partial refund?

Fees are calculated using the same method as for standard payments.

Stancer Customer Area ​

Why do Stancer User Area sessions expire quickly?

The current session duration is short: 5 minutes of inactivity. This configuration follows security recommendations regarding session management.

Is two-factor authentication (2FA) available?

Yes. 2FA is already enabled.

It is required:

  • Every 90 days
  • For sensitive actions.

It is currently not possible to require 2FA systematically at every login.

Can a Payer be banned from Stancer?

No, this feature is not currently available.

Security in the Event of Private Key Compromise ​

What happens if a private key is compromised?

A person with access to your private key could:

  • Create payments
  • View transactions
  • Initiate refunds

However, they could not directly recover captured funds, because Payouts are always made to your Bank Account. As with any payment service, protecting your private key is essential.