One session
curl -s "https://services.sandbox.payplug-elements.msem.tech/api/sessions/0193f6c1-7a2e-7b4d-9f01-2c3d4e5f6a7b" \ -H "authorization: Bearer $ACCESS_TOKEN"const response = await fetch("https://services.sandbox.payplug-elements.msem.tech/api/sessions/0193f6c1-7a2e-7b4d-9f01-2c3d4e5f6a7b", { headers: { authorization: `Bearer ${accessToken}` },});var response = client.send( HttpRequest.newBuilder(URI.create("https://services.sandbox.payplug-elements.msem.tech/api/sessions/0193f6c1-7a2e-7b4d-9f01-2c3d4e5f6a7b")) .header("authorization", "Bearer " + accessToken) .GET() .build(), HttpResponse.BodyHandlers.ofString());var request = new HttpRequestMessage(HttpMethod.Get, "https://services.sandbox.payplug-elements.msem.tech/api/sessions/0193f6c1-7a2e-7b4d-9f01-2c3d4e5f6a7b");request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", accessToken);var response = await http.SendAsync(request);$request = curl_init("https://services.sandbox.payplug-elements.msem.tech/api/sessions/0193f6c1-7a2e-7b4d-9f01-2c3d4e5f6a7b");curl_setopt_array($request, [ CURLOPT_RETURNTRANSFER => true, CURLOPT_HTTPHEADER => [ "authorization: Bearer $accessToken", ],]);$response = curl_exec($request);response = requests.get( "https://services.sandbox.payplug-elements.msem.tech/api/sessions/0193f6c1-7a2e-7b4d-9f01-2c3d4e5f6a7b", headers={"authorization": f"Bearer {access_token}"},)response = Net::HTTP.get_response( URI("https://services.sandbox.payplug-elements.msem.tech/api/sessions/0193f6c1-7a2e-7b4d-9f01-2c3d4e5f6a7b"), { "authorization" => "Bearer #{access_token}" })req, err := http.NewRequest("GET", "https://services.sandbox.payplug-elements.msem.tech/api/sessions/0193f6c1-7a2e-7b4d-9f01-2c3d4e5f6a7b", nil)if err != nil { return err}req.Header.Set("authorization", "Bearer "+accessToken)resp, err := http.DefaultClient.Do(req)if err != nil { return err}defer resp.Body.Close()let response = http .get("https://services.sandbox.payplug-elements.msem.tech/api/sessions/0193f6c1-7a2e-7b4d-9f01-2c3d4e5f6a7b") .bearer_auth(access_token) .send() .await?;curl -s "https://services.payplug-elements.msem.tech/api/sessions/0193f6c1-7a2e-7b4d-9f01-2c3d4e5f6a7b" \ -H "authorization: Bearer $ACCESS_TOKEN"const response = await fetch("https://services.payplug-elements.msem.tech/api/sessions/0193f6c1-7a2e-7b4d-9f01-2c3d4e5f6a7b", { headers: { authorization: `Bearer ${accessToken}` },});var response = client.send( HttpRequest.newBuilder(URI.create("https://services.payplug-elements.msem.tech/api/sessions/0193f6c1-7a2e-7b4d-9f01-2c3d4e5f6a7b")) .header("authorization", "Bearer " + accessToken) .GET() .build(), HttpResponse.BodyHandlers.ofString());var request = new HttpRequestMessage(HttpMethod.Get, "https://services.payplug-elements.msem.tech/api/sessions/0193f6c1-7a2e-7b4d-9f01-2c3d4e5f6a7b");request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", accessToken);var response = await http.SendAsync(request);$request = curl_init("https://services.payplug-elements.msem.tech/api/sessions/0193f6c1-7a2e-7b4d-9f01-2c3d4e5f6a7b");curl_setopt_array($request, [ CURLOPT_RETURNTRANSFER => true, CURLOPT_HTTPHEADER => [ "authorization: Bearer $accessToken", ],]);$response = curl_exec($request);response = requests.get( "https://services.payplug-elements.msem.tech/api/sessions/0193f6c1-7a2e-7b4d-9f01-2c3d4e5f6a7b", headers={"authorization": f"Bearer {access_token}"},)response = Net::HTTP.get_response( URI("https://services.payplug-elements.msem.tech/api/sessions/0193f6c1-7a2e-7b4d-9f01-2c3d4e5f6a7b"), { "authorization" => "Bearer #{access_token}" })req, err := http.NewRequest("GET", "https://services.payplug-elements.msem.tech/api/sessions/0193f6c1-7a2e-7b4d-9f01-2c3d4e5f6a7b", nil)if err != nil { return err}req.Header.Set("authorization", "Bearer "+accessToken)resp, err := http.DefaultClient.Do(req)if err != nil { return err}defer resp.Body.Close()let response = http .get("https://services.payplug-elements.msem.tech/api/sessions/0193f6c1-7a2e-7b4d-9f01-2c3d4e5f6a7b") .bearer_auth(access_token) .send() .await?;Everything the dashboard shows of a session: the split verdicts, the ack triples, the serving PSP, the notification calendar — and everything you sent with the order: the basket, the customer, the addresses, the travel details, the URLs. Another merchant’s session answers the same 404 as a nonexistent one.
Authorizations
Section titled “Authorizations”Parameters
Section titled “ Parameters ”Path Parameters
Section titled “Path Parameters”The session, as a search returned it. A lowercase UUID — the ones we mint are v7.
Example
0193f6c1-7a2e-7b4d-9f01-2c3d4e5f6a7bResponses
Section titled “ Responses ”One session in full: the dashboard view, plus everything the merchant sent with the order — basket, customer, addresses, travel, return and cancel URLs, descriptor.
object
Our handle for the session — the id the payer’s browser never sees.
Which merchant it belongs to.
The merchant’s own order reference — what you search on.
The payment journey, and nothing else. PENDING: open, the payer may still pay. CAPTURING: covered, the money is being taken. PAID: done. ABORTING/ABORTED: the payer gave up, holds released. EXPIRING/EXPIRED: the session timed out, holds released. AWAITING: a lender is studying the file (BNPL), nothing taken. AWAITED_REFUSED: that lender said no. The three terminal states — PAID, ABORTED, EXPIRED (and AWAITED_REFUSED) — are where you route away.
What the order costs.
object
Amount in the MINOR unit of the currency — 1000_00 is one thousand euros, never 1000.
ISO 4217 code, uppercase. One currency per session.
How much has actually been taken so far.
object
Amount in the MINOR unit of the currency — 1000_00 is one thousand euros, never 1000.
ISO 4217 code, uppercase. One currency per session.
Epoch milliseconds.
Epoch milliseconds.
Where this session’s ending was announced, and how that went. Absent: no callback was declared.
object
Where the ending is announced to the merchant.
When they acknowledged it — epoch milliseconds. Absent: still owed.
How many delivery attempts have failed so far (the calendar allows four).
The calendar is spent — nobody is coming (merchant-webhook Q6).
Every attempt of the session, oldest first.
object
Our handle for this attempt — what the refund door addresses.
When the attempt was opened — epoch milliseconds (Q13).
The last event that touched it — its transactions’ moves included.
Archetype of the method that carried it (card, oney…).
The method INSTANCE of the session it was started on.
The PSP adapter that served this attempt (D-051) — always present.
Where this attempt stands. AUTHORIZING: dispatched, verdict still due (always out-of-band). AUTHORIZED: the money is held. DECLINED: refused, nothing taken. CANCELLED: the payer backed out at the PSP. CAPTURED: taken. VOIDED: the hold was released.
Who decided a grant below the request: the payer in their app (chosen), or the issuer (mandated).
BNPL attempts only: the plan the payer chose.
object
How many instalments the payer took.
Whether that plan carried fees.
What the attempt asked for.
object
Amount in the MINOR unit of the currency — 1000_00 is one thousand euros, never 1000.
ISO 4217 code, uppercase. One currency per session.
What was actually authorized — what counts against the balance.
object
Amount in the MINOR unit of the currency — 1000_00 is one thousand euros, never 1000.
ISO 4217 code, uppercase. One currency per session.
How much of it has already been sent back.
object
Amount in the MINOR unit of the currency — 1000_00 is one thousand euros, never 1000.
ISO 4217 code, uppercase. One currency per session.
What can still be refunded on it — granted minus refunded, zero unless it settled.
object
Amount in the MINOR unit of the currency — 1000_00 is one thousand euros, never 1000.
ISO 4217 code, uppercase. One currency per session.
The card registration this attempt produced, when the order asked for one (for later merchant-initiated payments).
The card network this attempt ran on, as the PSP named it — visa, cb, mastercard, amex… Card attempts only, and only when the platform named one we could place: an absence means the verdict said nothing, never that the payment had no network.
The card as the PSP masked it — its first six and last four digits, the rest X — when it gave it.
The country of the card’s issuer, ISO 3166 alpha-2 — when the PSP gave it.
Money taken that nothing can hand back (direct-settlement) — the ops debt.
When this attempt’s settlement was recorded overdue — still without a verdict a day after the session’s term (the settlement-overdue alert). Epoch milliseconds. While the attempt is still AUTHORIZING, an administrator can conclude it from the dashboard.
Every PSP operation of this attempt, oldest first — the authorization, then its capture, void or refunds.
object
Our handle for this PSP operation — what a refund door addresses.
When the operation was opened — epoch milliseconds (Q13).
The last event that touched it — for a terminal transaction, its verdict’s instant.
What this operation asked the PSP: hold the money, take it in one go, capture a hold, release a hold, send money back, or debit the registered card later.
What this operation moved, in minor units.
object
Amount in the MINOR unit of the currency — 1000_00 is one thousand euros, never 1000.
ISO 4217 code, uppercase. One currency per session.
The PSP’s reference — what their dashboard greps (D-047).
The VERDICT facet: what the PSP finally decided about this operation — as opposed to the ack facet below, which is what the driving call answered on the spot.
object
Where the operation stands. pending means the verdict is still due — it always arrives out-of-band.
The PSP’s own code, split at the source — successes carry theirs too.
The PSP’s own sentence, as they said it — never glued to the code.
What a refusal means, when the PSP’s answer could be read.
What the driving call answered (the ack facet).
What the driving call said — a transport failure’s raw cause included.
Absent beside a present ackMessage = no HTTP response ever came.
The PSP’s own reference for the driving call’s exchange, when it named one — what its support asks for.
The caller’s reconciliation tag, on refunds only (lot 5) — echoed verbatim.
The refused operation this one replays — asked again by an administrator.
On a refund: the later debit it gives back — absent, the attempt’s own taking.
What waits for someone on this session — absent when nothing is open.
object
The kind of incident — the ops alert’s name.
Since when it is open, epoch ms.
The tranche it belongs to.
The operation it is about.
Nothing in the domain concludes it: an administrator says when it is dealt with from the dashboard. Otherwise it closes on its own.
The later debit this session allows — a card registered for the merchant to debit, on a method that can (POST /api/sessions/{sessionId}/debit). Absent when there is none.
object
The tranche that registered the card.
Last day the registration may be used (YYYY-MM-DD).
The ceiling: per debit — or, for a guarantee, all of them together.
object
Amount in the MINOR unit of the currency — 1000_00 is one thousand euros, never 1000.
ISO 4217 code, uppercase. One currency per session.
Why the card will be debited later.
What the debits already took or may still take (succeeded + in flight).
object
Amount in the MINOR unit of the currency — 1000_00 is one thousand euros, never 1000.
ISO 4217 code, uppercase. One currency per session.
A debit awaits its verdict — one at a time.
The incidents already said dealt with.
object
The operation acknowledged — a transaction, a tranche, or empty.
When, epoch ms.
What was done.
Who said it.
The disputes raised against this session’s payments, and their delivery to the merchant. Absent when there is none.
object
The dispute’s identifier — what the dashboard’s gestures on it name.
The PSP’s reference for the dispute.
chargeback (a debit) or representment (a credit).
object
Amount in the MINOR unit of the currency — 1000_00 is one thousand euros, never 1000.
ISO 4217 code, uppercase. One currency per session.
When the PSP raised it, epoch ms.
The document the merchant receives — event: chargeback.
object
Where it is delivered — absent when the merchant declared no address.
When the merchant acknowledged it, epoch ms.
Failed attempts of the current calendar.
Why the last attempt failed.
Never delivered, the retries spent — an incident.
Who attached it by hand — absent when its reference named the payment.
An abandoned dispute dealt with by hand.
object
When it was said dealt with, epoch ms.
Who said it.
What was done.
What the offer was matched against (method-acl.md) — the first thing to read when a method someone expected was not served.
object
ISO 3166-1 alpha-2 — where the order was sold.
The merchant’s own sales channel.
The basket as the merchant described it, line by line.
object
What the buyer reads for this line — shown as-is on the payment page.
How many units of it.
Price of the LINE — unit price × quantity, in minor units.
object
Amount in the MINOR unit of the currency — 1000_00 is one thousand euros, never 1000.
ISO 4217 code, uppercase. One currency per session.
PSP-facing itemization of this line. REQUIRED, in full, on a session that offers a BNPL method: the lender reads every field. Never shown to the payer — the payment page carries the label, the quantity and the amount, nothing of this block.
object
Your own catalogue reference. Required on a session that offers a BNPL method.
What this line IS, from the lender’s closed list. REQUIRED on every line of a session that offers a BNPL method — the platform has no default for what a shop sells.
Who sells this line. Required on a session that offers a BNPL method. The one field of detail the payment page sees: with group-cart-by-brand, a line shows its brand, and a brand’s lines show as one.
Discount already applied to this line, in minor units.
Tax included in this line, in minor units.
How this line is delivered. Every field of it is required on a session that offers a BNPL method: the lender reads them, and the platform substitutes nothing.
object
How the goods reach the buyer. Required on a BNPL session.
Required on a BNPL session.
Required on a BNPL session.
In days. Required on a BNPL session.
Required on a BNPL session.
Who is paying, as the merchant knows them. Personal data — the merchant’s own.
object
The buyer’s activity with your shop, handed to the 3-D Secure risk assessment (more history means a better chance of a frictionless authentication). Send what you know.
object
Purchases in the last 24 hours.
Purchases in the last 12 months.
Purchases in the last 6 months.
Merchant-side unique customer identifier.
The buyer’s e-mail — where the PSP and the lender write, when they do.
The buyer’s own name. Used as the cardholder name when the card form does not collect one.
The buyer’s family name.
The billing address sent with the order.
object
Company at this address, when there is one. Oney requires it on the shipping block.
Given name of the person at this address.
Family name of the person at this address.
Civility, PSP-normalized.
Street line — number, street, complement.
Postal code as the country writes it.
City or town.
ISO 3166-1 alpha-2.
International format.
International format.
The shipping address sent with the order.
object
Company at this address, when there is one. Oney requires it on the shipping block.
Given name of the person at this address.
Family name of the person at this address.
Civility, PSP-normalized.
Street line — number, street, complement.
Postal code as the country writes it.
City or town.
ISO 3166-1 alpha-2.
International format.
International format.
The travel details sent with the order.
object
Who travels — the lead traveller, when the contract asks for one.
object
Given name of the lead traveller.
Family name of the lead traveller.
Date of birth, YYYY-MM-DD.
One entry per stay of the trip.
object
Where the stay takes place — resort, city, site.
Arrival, YYYY-MM-DD.
Departure, YYYY-MM-DD.
What kind of stay it is, in your own words.
How many rooms or units.
How many people travel.
Whether the order includes travel insurance.
Whether the order includes a vehicle rental.
Where the payer is sent once it ends.
Where the payer is sent when they give up.
The soft descriptor — what the buyer reads on their bank statement.
The merchant’s own free text, carried to the PSP.
The order asked for a card alias to be created.
Example
{ "status": "PENDING", "attempts": [ { "status": "AUTHORIZING", "partialAuth": "chosen", "cardScheme": "visa", "cardCode": "497010XXXXXX0007", "cardCountry": "FR", "settlementOverdueAt": 1791000000000, "transactions": [ { "type": "authorization", "status": { "kind": "pending", "category": "bank-refusal" } } ] } ], "cartItems": [ { "detail": { "category": "computersandsoftware", "delivery": { "type": "storepickup", "speed": "standard" } } } ], "billing": { "title": "mr" }, "shipping": { "title": "mr" }}InvalidRequest — the request could not be read: a missing or malformed field, a bad pattern, or a property this door does not declare (the message names it). Every door with a schema can answer this, before any business rule is consulted.
object
Stable machine-readable code — the one thing to branch on. Never parse the message.
English sentence for logs and operators. Wording may change; the code will not.
Example
{ "code": "InvalidRequest", "message": "body/<field> failed validation"}Unauthorized — the only code this response carries: no usable access token (absent, malformed, expired). One answer for every failure shape, so nothing can be learned by watching which one comes back.
object
Stable machine-readable code — the one thing to branch on. Never parse the message.
English sentence for logs and operators. Wording may change; the code will not.
Example
{ "code": "Unauthorized", "message": "a valid access token is required"}NotFound — the only code this response carries: unknown, or belonging to another merchant. The two are deliberately indistinguishable.
object
Stable machine-readable code — the one thing to branch on. Never parse the message.
English sentence for logs and operators. Wording may change; the code will not.
Example
{ "code": "NotFound", "message": "no such resource"}