Skip to content
/Payment Session

Payment Session

A Payment Session is a configurable workflow that wraps a payment journey with pre-steps and/or post-steps — such as identity verification, compliance checks, or data collection — before or after the core payment. The session type is configured per business and determines the exact step sequence. Creating a session returns a short-lived JWT token that is passed to the Glomo Web SDK to launch the guided UI.

Operations

Create a payment session

Request

Creates a payment session — a configurable workflow that wraps a payment journey with pre-steps and/or post-steps such as identity verification, compliance checks, or data collection. The exact step sequence is determined by the session_type configured for your business.

Example: The kyc_lrs session type adds a KYC verification step before the LRS remittance checkout, ensuring the customer is verified before funds are transferred.

The token returned in the response should be passed to the Glomo Web SDK to launch the guided UI for the customer.

Optionally associate the session with an existing customer via customer_id, or pre-populate customer details using email. Both fields are optional and mutually exclusive — passing both returns a 400 error. Omitting both creates an anonymous session.

Prefilling steps: Pass prefill data to pre-populate steps in the flow so the customer skips re-entering known values. Include only the data relevant to your session_type.

  • KYC prefill — identity details (pan, phone, country, dob) used to prefill the KYC step. Two request shapes are supported: v1 places the kyc object at the top level; v2 nests it under data.kyc (recommended, and the shape used alongside other data groups). Provide only one shape — supplying kyc at both the top level and under data returns a 400 error. When any of pan, phone, or dob is supplied, pair it with email; these fields cannot be combined with customer_id (which is authoritative), and supplying them without any identifier returns a 400 error. When phone is supplied, country (ISO 3166-1 alpha-3) is required and is used to validate the phone number format.

  • Scheme prefill (data.scheme) — investment scheme details (plan, amount, currency, distributor_arn) used to prefill the scheme plan and amount step. amount and currency must be supplied together.

Contact support if you receive a 403 error — payment sessions must be enabled for your business.

Security
JWT
Bodyapplication/json
customer_idstring

The unique identifier of an existing customer (cust_ prefix). Mutually exclusive with email.

Example:"cust_abc123XYZ"
emailstring, (email)

Email address to pre-populate customer details in the session flow. Mutually exclusive with customer_id.

Example:"john.doe@example.com"
kycobject

KYC prefill (v1) — identity details used to prefill the KYC step. Equivalent to data.kyc (v2, recommended); provide one shape or the other, not both. Only accepted when customer_id or email is also provided at the top level.

dataobject

Optional container for prefill data. Include only the groups relevant to your session_type; unknown groups are ignored.

POST
/payment-sessions
curl -i -X POST \
  https://api.glomopay.com/api/v1/payment-sessions \
  -H 'Authorization: Bearer <YOUR_JWT_HERE>' \
  -H 'Content-Type: application/json' \
  -d '{}'

Responses

Payment session created successfully.

Bodyapplication/json
idstring

Unique identifier for the payment session, prefixed with psess_.

Example:"psess_6819d8046mpKt"
statusstring

Current status of the payment session.

Example:"active"
session_typestring

The workflow type configured for this session, which determines the pre-steps and/or post-steps in the payment journey. The value is configured per business. For example, kyc_lrs adds KYC verification before the LRS remittance checkout.

Example:"kyc_lrs"
tokenstring

Short-lived JWT token to be passed to the Glomo Web SDK to launch the session UI for the customer.

Example:"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
expires_atstring, (date-time)

ISO 8601 timestamp when the session expires.

Example:"2026-05-07T10:30:00Z"
Response
{
  "id": "psess_6819d8046mpKt",
  "status": "active",
  "session_type": "kyc_lrs",
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "expires_at": "2026-05-07T10:30:00Z"
}