Skip to content

API

Introduction

To offer an easy-to-use experience, we offer libraries in Shell, Python, Perl or PHP and the list keeps getting longer.

Code examples are displayed in each section. Tabs available in the menu allow you to switch them to various programming languages.

The API is available at https://api.stancer.com and supports TLS 1.2, HTTP/1.1 and HTTP/2.

Our documentation is also available in Swagger or Redoc format.

INFO

This documentation uses httpie for shell examples, and our libraries for PHP, Python & Perl examples.

Key concepts

The same API can be used to access live resources processing real payments and payment methods, but also test resources for your software development and debug purpose. Our API service use API keys to authenticate requests.

You can register for an API key at our website. API keys are in the form of sprod_xxx for your live requests and stest_xxx for your test ones.

The authentication to the API is performed via HTTP Basic Auth. You must use your API key as username and provide no password.

We advise you to use the basic auth mecanism of your HTTP toolkit, but if you need to handle it manually, as specified in HTTP Basic Auth RFC, you need to encode your API key in base64 before sending the corresponding authenticationc token in an Authorization HTTP header. For example, if your API key is sprod_xxx, you need to encode sprod_xxx: (remember, empty password) in base64 (given c3Byb2RfeHh4Og==) then send a Authorization: Basic c3Byb2RfeHh4Og== HTTP header.

This documentation focus on common use case workflows.

For technical documentation, please refer to our OpenAPI documentations, Swagger or Redoc.

If you need technical support about our API integration, you can join our Slack community.

Create payments

Through integrated payment page

shell
$ http --auth stest_xxx: https://api.stancer.com/v2/customers/ \
    name="Foo Bar" email=foo.bar@example.org
{
    "id": "cust_xxx",

}

$ http --auth stest_xxx: https://api.stancer.com/v2/payments/ \
currency=eur amount=100 customer=cust_xxx description="Test payment" auth=True
{
    "id": "paym_xxx",

}

To create a payment, use the POST /v2/payments route. You need to at least provide a currency and an amount.

If you want to associate the payment with a customer, you can use the customer field and pass the corresponding cust_xxx ID.

Note you currently have to force 3DS validation with the auth=true parameter. Else your customer won't be able to proceed the payment as his bank will surely refuse a not authenticated payment.

You can now send your customer on the payment page located at https://payment.stancer.com/ptest_xxx/paym_xxx. Replace public key and payment ID accordingly.

Once payment is created, you can modify it until capture for example to reflect a purchase change, using PATCH /v2/payments/{id} method.

shell
$ http --auth stest_xxx: https://api.stancer.com/v2/payments/paym_xxx amount=200

Through API

shell
$ http --auth stest_xxx: https://api.stancer.com/v2/cards/ \
    name="Foo Bar" number=4242424242424242 exp_month=10 exp_year=2024 cvc=424
{
    "id": "card_xxx",

}

$ http --auth stest_xxx: https://api.stancer.com/v2/payments/ \
currency=eur amount=100 customer=cust_xxx description="Test payment" \
card=card_xxx auth[return_url]=http://example.org
{
    "id": "paym_xxx",
    "auth": {
        "redirect_url": "https://3ds.iliad78.net/v2/redirect/xxx",

    }

}

If you prefer to collect by yourself the card number, you can process a payment directly and tokenize the sensible information with POST /v2/cards before using it elsewhere in API calls.

You need to specify a return_url to handle 3DS authentication. At the end of the 3DS process, we will redirect your customer to this URL.

shell
$ http --auth stest_xxx: https://api.stancer.com/v2/payments/paym_xxx
{

    "auth": {
        "status": "success"
    }
}

$ http --auth stest_xxx: PATCH https://api.stancer.com/v2/payments/paym_xxx \
status=capture

Then send your customer on the given auth[redirect_url] to proceed with 3DS. After the redirect to your return_url, you need to check for authentication validity, then capture the payment if all is good.

Capture payments

To manually capture a payment via our API, follow the steps in order to avoid any errors.

Prepare your environment

Before getting started, make sure you have:

  • An API client If you don’t have a client, you can use Postman, a free tool for sending API requests.

  • The API package Download the package from our Redoc by clicking the "Download" button at the top of the page.

Download Package API

  • Your private key You must have your private key to authenticate. You can find it in the Developers section of your Customer Area (Ex: sprod_xxx).

Authentication

Before performing the capture, you must authenticate using your private key.

In Postman:

  • Go to the Auth tab at the root of the Stancer API Collection.
  • Select Basic Auth.
  • In the "username" field, enter your private key sprod_xxx. This allows the API to recognize that you are authorized to perform this action.



Perform the capture

You will need to:

  • Click on the payments route, then id You will see the request already pre-filled with the variable , which uses the Stancer API domain.
  • Replace ":id" with the paym_xxx you want to capture
  • Click on Send to send the request.

Each of your online payments with the status "authorized" must be captured in this way.

API status code

Payment status

The status field in the payment object indicates in which state is the payment.

StatusMeaning
📋 authorizedThe bank authorized the payment but the transaction will only be processed after asking for capture
📋 to_captureThe bank authorized the payment, money will be processed within the day
📋 capture_sentThe capture operation is being processed, the payment can not be cancelled anymore, refunds must wait the end of the capture process
📋 capturedThe amount of the payment have been credited to your account
📋 disputedThe customer declined the payment after it have been captured on your account
📋 expiredThe authorisation was not captured and expired after 7 days
📋 failedThe payment has failed, refer to the response field for more details
📋 refusedThe payment has been refused

Authenticated payment status codes

The status field in the auth object returns the authorisation state for an authenticated payment.

StatusMeaning
📋 availableCustomer strong authentication is possible
📋 requestedA strong authentication is awaiting for more information
📋 attemptedCustomer was redirected to his bank for authentication
📋 successAuthentication succeeded, processing can continue
📋 declinedAuthentication declined
📋 expiredAuthentication sessions expired after 6 hours
📋 failedAuthentication failed
📋 unavailableThe strong authentication is not available for this payment method

Payout status codes

The status field in the payout explains in which state is the credit transfer which wires funds from Stancer to your bank.

StatusMeaning
📋 pendingThe payout has been created and is awaiting for clearing
📋 to_payThe payout is ready to be transfered
📋 sentThe payout has been sent out for processing
📋 paidThe payout credit transfer has been processed: funds have been received by your bank
📋 failedThe credit transfer has failed, please refer to you dashboard for more informations

Card response codes

⚠️ = real code & reason must not be sent to the customer, replace them with a generic 05 do-not-honor.

CodeMeaning
📋 00Successful approval/completion or that VIP PIN verification is valid
📋 01Refer to card issuer
📋 02Refer to card issuer, special condition
📋 03Invalid merchant or service provider
📋 04Pickup
📋 05Do not honor
📋 06General error
📋 07Pickup card, special condition (other than lost/stolen card)
📋 08Honor with identification
📋 09Request in progress
📋 10Partial approval
📋 11VIP approval
📋 12Invalid transaction
📋 13Invalid amount (currency conversion field overflow) or amount exceeds maximum for card program
📋 14Invalid account number (no such number)
📋 15No such issuer
📋 16Insufficient funds
📋 17Customer cancellation
📋 19Re-enter transaction
📋 20Invalid response
📋 21No action taken (unable to back out prior transaction)
📋 22Suspected Malfunction
📋 25Unable to locate record in file, or account number is missing from the inquiry
📋 28File is temporarily unavailable
📋 30Format error
📋 34⚠️Suspected fraud
📋 41⚠️Merchant should retain card (card reported lost)
📋 43⚠️Merchant should retain card (card reported stolen)
📋 51Insufficient funds
📋 52No checking account
📋 53No savings account
📋 54Expired card
📋 55Incorrect PIN
📋 56Card missing from file
📋 57Transaction not permitted to cardholder
📋 58Transaction not allowed at terminal
📋 59⚠️Suspected fraud
📋 61Activity amount limit exceeded
📋 62⚠️Restricted card (for example, in country exclusion table)
📋 63⚠️Security violation
📋 65⚠️Activity count limit exceeded
📋 68Response received too late
📋 75Allowable number of PIN-entry tries exceeded
📋 76Unable to locate previous message (no match on retrieval reference number)
📋 77Previous message located for a repeat or reversal, but repeat or reversal data are inconsistent with original message
📋 78’Blocked, first used’—The transaction is from a new cardholder, and the card has not been properly unblocked.
📋 80Visa transactions: credit issuer unavailable. Private label and check acceptance: Invalid date
📋 81PIN cryptographic error found (error found by VIC security module during PIN decryption)
📋 82Negative CAM, dCVV, iCVV, or CVV results
📋 83Unable to verify PIN
📋 85No reason to decline a request for account number verification, address verification, CVV2 verification; or a credit voucher or merchandise return
📋 91Issuer unavailable or switch inoperative (STIP not applicable or available for this transaction)
📋 92Destination cannot be found for routing
📋 93⚠️Transaction cannot be completed, violation of law
📋 94Duplicate transmission
📋 95Reconcile error
📋 96System malfunction, System malfunction or certain field error conditions
📋 98Server inaccessible
📋 A0Authentication Required, you must do a card inserted payment with PIN code
📋 A1Authentication Required, you must do a 3-D Secure authentication
📋 A2Pin request in Single TAP mode
📋 B1Surcharge amount not permitted on Visa cards (U.S. acquirers only)
📋 N0Force STIP
📋 N3Cash service not available
📋 N4Cashback request exceeds issuer limit
📋 N7Decline for CVV2 failure
📋 P2Invalid biller information
📋 P5PIN change/unblock request declined
📋 P6Unsafe PIN
📋 Q1Card authentication failed
📋 R0Stop payment order
📋 R1Revocation of authorization order
📋 R3Revocation of all authorizations order
📋 XAForward to issuer
📋 XDForward to issuer
📋 Z1Offline-declined
📋 Z3Unable to go online
📋 7810⚠️Refusal count exceeded for this card / sepa
📋 7811⚠️Exceeded payment volume for this card / sepa
📋 7812⚠️Card temporarily frozen by the customer's bank
📋 7840⚠️Stolen or lost card
📋 7898Bank server unavailable

Dispute response codes

⚠️ = real code & reason must not be sent to the customer, replace them with a generic 45 transaction-disputed.

ResponseNetworkMeaning
📋 14NationalTransaction not authorized
📋 42NationalDuplicate processing
📋 45NationalTransaction disputed
📋 1040⚠️VisaFraud; card Absent Environment
📋 1261VisaDuplicate processing
📋 4808MastercardRequested/required authorization not obtained. Transaction not authorized
📋 4834MastercardDuplicate processing
📋 4837⚠️MastercardFraudulent transaction; no cardholder authorization
📋 4853MastercardCardholder Dispute Defective/Not as Described
📋 4863⚠️MastercardCardholder does not recognize. Potential fraud

SEPA Dispute response codes

CodeISO definitionExhaustive list of uses-cases
AC01Incorrect Account NumberSDD B2B collection presented to a payment account whereby the Debtor account holder is a consumer or the payment account type is designed to consumers only.
AC04Closed Account NumberThe account of the Debtor is closed at the Debtor PSP. Note: This code cannot be used in certain SEPA countries for reasons of data protection. MS03 could be used as an alternative.
AC06Blocked AccountAccount blocked for any financial transaction.
AC13Invalid Debtor Account TypeSDD B2B collection presented to a payment account whereby the Debtor account holder is a consumer or the payment account type is designed to consumers only.
AG01Transaction ForbiddenA SDD collection cannot be booked from this type of account (account not allowed for direct debit for regulatory reasons e.g., savings account). Important note: AG01 cannot be used in the situation of an SDD B2B collection presented to a Debtor account that is a consumer account. The code AC13 needs to be used.
AG02Invalid Bank Operation CodeRecurrent after a one-off / One-off after a recurrent / Identification code of thescheme (i.e. service level or local instrument) specified in the message is incorrect
AM04Insufficient FundsThere are not enough funds on the Debtor account to debit the full amount of the collection. Note: This code cannot be used in certain SEPA countries for reasons of data protection. MS03 could be used as an alternative
AM05DuplicationCSM or Debtor PSP considers that an identical SDD collection had been sent or processed very recently
BE05Unrecognised Iniating PartyCreditor Identifier (CI) is not correct or has been changed without an amendment been reported.
CNORCreditor Bank Is Not RegisteredCreditor PSP is not/ no longer registered as a SDD scheme participant under this BIC at the CSM.
DNORDebtor Bank Is Not RegisteredDebtor PSP is not/ no longer registered as a SDD scheme participant under this BIC at the CSM.
ED05Settlement FailedThe Debtor PSP or the CSM must report a settlement failure.
FF01Invalid File FormatIssues with XML-file specific settings:
• XML file was not duly filled out or is not correct
• There is a syntax error in the file
• Creditor PSP, its intermediary PSP or the CSM did not complete a XSD check before submitting the file into the scheme.
MD01No Mandate• No mandate is existing
• B2B mandate not yet confirmed by the Debtor
• Refund for an unauthorised transaction (until 13 months after debit date) (For SDD Core collections only)
• Mandate cancellation
MD02Missing Mandatory Mandate Information in Mandate• Mandate data in the mandate related information is not identical to those in the mandate (amendments had not been communicated)
• Mandate data not consistent with version already received for the UMR
• In case of mandate amendment: the original IBAN
MD06Refund Request By End CustomerUnconditional Refund of a collection (SDD Core – until 8 weeks after debit date).
MD07End Customer DeceasedDebtor deceased. Note: This code cannot be used in certain SEPA countries for reasons of data protection. In this case MS03 can be used as alternative.
MS02Not Specified Reason Customer GeneratedRefusal by Debtor at presentation.
MS03Not Specified Reason Agent GeneratedOnly to be used in case national legislation (e.g., data protection laws) does not allow the use of AC04, AM04, MD07, RR01, RR02, RR03 and RR04. Note: limit the use of the reason code MS03 and select the appropriate reason code in the list.
RC01Bank Identifier IncorrectBIC of the scheme participant is not correct.
RR01Missing Debtor Account Or IdentificationMissing details about the Debtor account or identification. Note: This code cannot be used in certain SEPA countries for reasons of data protection. MS03 could be used as an alternative.
RR02Missing Debtor Name Or AddressMissing Debtor name (address is optional field for EEA SDD collections); Missing address of the Debtor for non-EEA SDD collections. Note: This code cannot be used in certain SEPA countries forreasons of data protection. MS03 could be used as an alternative.
RR03Missing Creditor Name OR AddressMissing Creditor name (address is an optional field). Note: This code cannot be used in certain SEPA countries for reasons of data protection. MS03 could be used as an alternative.
RR04Regulatory ReasonOnly to be used for regulatory reasons other than RR01, RR02 or RR03. Note: This code cannot be used in certain SEPA countries for reasons of data protection. MS03 could be used as an alternative.
SL01Specific Service Offered By Debtor AgentAll Debtor-invoked consumerright rejects:
• Creditor blocking
• Collection amount limitations
• Collection frequency limitations. Other services offered by the Debtor PSP.

Test data

Test cards

WARNING

These test cards are intended solely for simulating specific scenarios (examples: Disputes, Captured payments...). Using them in a normal payment flow may lead to unexpected behaviors and compromise the integrity of your integrations. Use with caution and only in a test environment.

NumberBrandCountry3DSReturnUsage
📋 4000000400000008VisaAT 🇦🇹Optional00 OKPayment Page
📋 4000000560000004VisaBE 🇧🇪Optional00 OKPayment Page
📋 4000002080000001VisaDK 🇩🇰Optional00 OKPayment Page
📋 4000002460000001VisaFI 🇫🇮Optional00 OKPayment Page
📋 4000002500000003CBFR 🇫🇷Optional00 OKPayment Page
📋 4000002760000016VisaDE 🇩🇪Optional00 OKPayment Page
📋 4000003720000005VisaIE 🇮🇪Optional00 OKPayment Page
📋 4000003800000008VisaIT 🇮🇹Optional00 OKPayment Page
📋 4000004420000006VisaLU 🇱🇺Optional00 OKPayment Page
📋 4000005280000002VisaNL 🇳🇱Optional00 OKPayment Page
📋 4000005780000007VisaNO 🇳🇴Optional00 OKPayment Page
📋 4000006200000007VisaPT 🇵🇹Optional00 OKPayment Page
📋 4000006430000009VisaRU 🇷🇺Optional00 OKPayment Page
📋 4000007240000007VisaES 🇪🇸Optional00 OKPayment Page
📋 4000007520000008VisaSE 🇸🇪Optional00 OKPayment Page
📋 4000007560000009VisaCH 🇨🇭Optional00 OKPayment Page
📋 4000008260000000VisaGB 🇬🇧Optional00 OKPayment Page
📋 4242424242424242VisaUS 🇺🇸Not required00 OKPayment Page
📋 4444333322221111VisaUS 🇺🇸Not required00 OKPayment Page
📋 4111111111111111VisaUS 🇺🇸Not required00 OKPayment Page
📋 5555555555554444MastercardUS 🇺🇸Optional00 OKPayment Page
📋 5200828282828210MastercardUS 🇺🇸Optional00 OKPayment Page
📋 5105105105105100MastercardUS 🇺🇸Optional00 OKPayment Page
📋 4000000000003055VisaUS 🇺🇸Not enrolled00 OKPayment Page
📋 4000000760000002VisaBR 🇧🇷Optional00 OKPayment Page
📋 4000001240000000VisaCA 🇨🇦Optional00 OKPayment Page
📋 4000004840000008VisaMX 🇲🇽Optional00 OKPayment Page
📋 4000000000000077VisaFR 🇫🇷Optional00 OK | status = 50 capturedAPI (HPP, TTPOI, TPE, CMS etc)
📋 4000000000003220VisaUS 🇺🇸RequiredA1 must perform 3DS | status = 0 refusedPayment Page
📋 4000000000000002VisaFR 🇫🇷Optional05 do not honor | status = 0 refusedPayment Page
📋 4000000000009995VisaFR 🇫🇷Optional51 insufficient fund | status = 0 refusedPayment Page
📋 4000000000009987VisaFR 🇫🇷Optional41 lost card | status = 0 refusedPayment Page
📋 4000000000000259VisaFR 🇫🇷Optional00 OK | status = 60 disputedAPI (HPP, TTPOI, TPE, CMS etc)
📋 4000000000001976VisaFR 🇫🇷Optional00 OK | status = 60 disputedAPI (HPP, TTPOI, TPE, CMS etc)
📋 4000000000005423VisaFR 🇫🇷Optional00 OK | status = 60 disputedAPI (HPP, TTPOI, TPE, CMS etc)

Test SEPA

IBANCountryNameBirthdateReturn
📋 AT611904300234573201AT 🇦🇹Otto Normalverbraucher1971-02-0200 OK
📋 BE62510007547061BE 🇧🇪Jef Van Pijperzele1972-03-0300 OK
📋 CH2089144321842946678CH 🇨🇭Leonhard Euler1973-04-0400 OK
📋 DE89370400440532013000DE 🇩🇪Max Mustermann1974-05-0500 OK
📋 EE382200221020145685EE 🇪🇪Friedrich Robert Faehlmann1975-06-0600 OK
📋 ES0700120345030000067890ES 🇪🇸Juan Pérez1976-07-0700 OK
📋 FI2112345600000785FI 🇫🇮Maija Meikäläinen1977-08-0800 OK
📋 FR1420041010050500013M02606FR 🇫🇷Pierre Martin1978-09-0900 OK
📋 GB33BUKB20201555555555GB 🇬🇧John Doe1970-01-0100 OK
📋 IE29AIBK93115212345678IE 🇮🇪John Kilkenny1979-10-1000 OK
📋 LT121000011101001000LT 🇱🇹Jonas Petraitis1980-11-1100 OK
📋 LU280019400644750000LU 🇱🇺Adalbert Boros1981-12-1200 OK
📋 IT02A0301926102000000490887IT 🇮🇹Piero Pers1982-01-1300 OK
📋 NL39RABO0300065264NL 🇳🇱Jan Modaal1983-02-1400 OK
📋 NO9386011117947NO 🇳🇴Peder Aas1984-03-1500 OK
📋 PT50000201231234567890154PT 🇵🇹Jan Kowalski1985-04-1600 OK
📋 SE3550000000054910000003SE 🇸🇪Lisa Svensson1986-05-1700 OK
📋 FR9430003000409249176322Z50FR 🇫🇷Gilles Dupont1987-06-1800 OK
📋 FR2990665286926539507769811FR 🇫🇷Jean Banbois1992-11-23AC01 Incorrect Account Number | status = 0 refused
📋 FR8191676442817818484578833FR 🇫🇷Marie-Jeanne Sansbanque1993-12-24AC04 Closed Account Number | status = 0 refused
📋 FR3083648641551044006702169FR 🇫🇷Marc Barrer1994-01-25AC06 Blocked Account | status = 0 refused
📋 FR4200838098473368525032012FR 🇫🇷Sophie Fontek1995-02-26AG01 Transaction Forbidden | status = 0 refused
📋 FR7099253427049384102178149FR 🇫🇷Hector Fauché1996-03-27AM04 Insufficient Funds | status = 0 refused
📋 FR7240745948453163519978561FR 🇫🇷Lillianne Sansmandat1997-04-28MD01 No Mandate | status = 0 refused
📋 FR5533686478441573584650545FR 🇫🇷Vincent Refusé1998-05-29MD06 Refund Request By End Customer | status = 0 refused
📋 FR2488294045573706143240475FR 🇫🇷Eric Indécis1999-06-30MS02 Not Specified Reason Customer Generated | status = 0 refused
📋 BE08510007547063BE 🇧🇪Camille Honnête1988-07-19AM04 Insufficient Funds | status = 60 disputed
📋 ES5000120345030000067892ES 🇪🇸Pepito Pérez1990-09-21AC04 Closed Account Number | status = 60 disputed