Skip to content

Create a session

The two calls your server makes, authenticate, then create the payment session, then receive the token to hand to your page.

The two steps that happen on your server before your checkout page renders.

Exchange your credentials for an access token. This token lasts a while: cache it and reuse it until expiration.

# jq (https://jqlang.github.io/jq) reads the answers; both steps share $ACCESS_TOKEN.
GRANT=$(curl -s -X POST "https://services.sandbox.payplug-elements.msem.tech/oauth/token" \
-H "content-type: application/x-www-form-urlencoded" \
--data-urlencode "grant_type=client_credentials" \
--data-urlencode "client_id=$MERCHANT_ID" \
--data-urlencode "client_secret=$MERCHANT_SECRET")
ACCESS_TOKEN=$(echo "$GRANT" | jq -r .access_token)
EXPIRES_IN=$(echo "$GRANT" | jq -r .expires_in)

Now declare a payment session for an order.

ELEMENTS_TOKEN=$(curl -s -X POST "https://services.sandbox.payplug-elements.msem.tech/api/sessions" \
-H "content-type: application/json" \
-H "authorization: Bearer $ACCESS_TOKEN" \
-d '{
"currency": "EUR",
"total": 100000,
"orderId": "EP-123456",
"methods": [{ "method": "card" }],
"returnUrl": "https://shop.example.com/checkout"
}' | jq -r .elementsToken)

A few things worth knowing about the request body:

  • The merchant is inferred from the token: a session belongs to the merchant who authenticated.
  • orderId is required and travels with every PSP transaction: a split payment sends several operations with that same reference.
  • total and every amount in this API are in minor units (cents for euros).
  • methods declares what you want for this order. For the configuration of the payment methods, see payment methods.

The answer carries an opaque, short-lived elementsToken. That is the only thing the browser ever needs.

Your page takes it from there: see show the elements.