# Get started with Glomo

Glomo is a cross-border payments platform. Each product section holds two kinds of page. Pages titled as a noun, such as *Subscriptions*, explain what an object is. Pages titled as a job, such as *Set up recurring subscriptions*, are integration guides that give the APIs in the order you call them. A guide sits one level under the object it sets up.

## What are you building?

Pick the section that matches your integration. Each one lists the calls in order and links the full guide.

- A step that starts with an `operationId` is an API call. Look it up in the [API reference](/api-reference/openapi) or in [/openapi.json](/openapi.json).
- **Not an API call** marks a step in your frontend or your server, or a webhook you wait for.


Shared calls: `createCustomer` and `createOrder` are the same calls in every collection flow, LRS included. `createBeneficiaryV2` and `createPayout` are the same calls for payouts and for LRS withdrawals. Create each customer once and reuse the returned ID. Purpose codes come from closed lists, one for [payins](/payin/purpose-codes) and one for [payouts](/payout/purpose-codes). Pick from the list; never guess a code.

## One-time collection

For merchants collecting a single payment against an order or a payment link. Use the Payment API variant only if you are PCI-DSS certified and your account has server-to-server payments enabled.

### SDK checkout

1. `createCustomer` `POST /customer` — create the payer once and store the `cust_` ID.
2. `createOrder` `POST /orders` — call it from your server with your secret key. Send a `request_id`; a reused one is rejected.
3. **Not an API call:** open Glomo checkout with the Unified SDK, passing the order ID and your public key.
4. **Not an API call:** on your server, verify the signature on the checkout response. Check it against each of your active secret keys; any one matching is valid.
5. `getPaymentById` `GET /payment/{id}` — confirm the final status, or take it from the `payment` webhook. Never mark an order paid from the browser alone.


Full guide: [Checkout](/payin/checkout)

### Payment API (server-to-server)

1. `createCustomer` `POST /customer` — create the payer once and store the `cust_` ID.
2. `createOrder` `POST /orders` — send a `request_id`; a reused one is rejected.
3. `createPayment` `POST /payment` — send `order_id`, `method: card`, the card and an HTTPS `callback_url`. A `request_id` is optional; a reused one is rejected.
4. **Not an API call:** send the customer to the URL in `next_steps` to authenticate the card (3DS).
5. **Not an API call:** on your `callback_url`, verify the `signature` query parameter. Check it against each of your active secret keys; any one matching is valid.
6. `getPaymentById` `GET /payment/{id}` — confirm the final status, or take it from the `payment` webhook.


Full guide: [Accept card payments server-to-server](/payin/server-to-server-payments)

### Payment link (no frontend)

1. `createCustomer` `POST /customer` — create the payer once and store the `cust_` ID.
2. `createPayin` `POST /payin` — `purpose_code` is required unless your account has a default one. There is no `request_id`, so check whether a timed-out create went through before you retry.
3. **Not an API call:** the customer opens the glomo-hosted link and pays.
4. `getPayinById` `GET /payin/{id}` — the link is `paid` when complete. The `payment_link` webhook reports the same change.


Full guide: [Payment Link](/payin/payment-link)

## Subscriptions

For merchants charging a customer's card on a fixed schedule (`month` or `year`) or whenever they present a charge (`as_presented`). The Payment API variant has the same PCI-DSS and account requirement as in one-time collection.

### SDK checkout

1. `createCustomer` `POST /customer` — create the payer once and store the `cust_` ID.
2. `createSubscription` `POST /subscriptions` — set `interval_type`. For `as_presented`, send `max_amount`, leave out `interval_count`, `billing_cycles` and `start_date`, and don't set `starts_with_first_payment` to `false`.
3. **Not an API call:** open Glomo checkout with the Unified SDK, passing the subscription ID and your public key, to take the first payment.
4. **Not an API call:** on your server, verify the signature on the checkout response. Check it against each of your active secret keys; any one matching is valid.
5. `getPaymentById` `GET /payment/{id}` — confirm the first payment, or take it from the `payment` webhook.
6. `createPayment` `POST /payment` — `as_presented` only: charge each later payment with `subscription_id`, `sequence: subsequent`, `amount` (up to `max_amount`), `currency` and a new `request_id`. Glomo charges `month` and `year` subscriptions on schedule.


Full guide: [Set up recurring subscriptions](/payin/subscriptions/set-up)

### Payment API (server-to-server)

1. `createCustomer` `POST /customer` — create the payer once and store the `cust_` ID.
2. `createSubscription` `POST /subscriptions` — set `interval_type`, as in the SDK checkout variant.
3. `createPayment` `POST /payment` — the first payment: send `subscription_id` (not `order_id`), `method: card`, the card and an HTTPS `callback_url`.
4. **Not an API call:** send the customer to the URL in `next_steps` to authenticate the card (3DS).
5. **Not an API call:** on your `callback_url`, verify the `signature` query parameter. Check it against each of your active secret keys; any one matching is valid.
6. `createPayment` `POST /payment` — `as_presented` only: charge each later payment with `subscription_id`, `sequence: subsequent`, `amount` (up to `max_amount`), `currency` and a new `request_id`.


Full guide: [Accept card payments server-to-server](/payin/server-to-server-payments)

## LRS remittance

For Indian brokers and platforms that remit funds abroad for resident Indian investors under the Liberalised Remittance Scheme, and withdraw them back to the investor.

### Remittance

1. `getLrsBanks` `GET /lrs/banks` — optional: list the investor banks the remittance flow supports.
2. `createCustomer` `POST /customer` — create the investor once. LRS customers have stricter rules; see the guide.
3. `createLrsCustomerBankAccount` `POST /customer/{id}/bank_account` — register the investor's bank account and store its ID.
4. `createBeneficiaryV2` `POST /v2/beneficiaries` — optional: only when the overseas beneficiary differs per investor or per transaction. Use `category: lrs`.
5. `createLrsQuote` `POST /lrs/quotes` — quote the remittance for the investor's bank. A quote expires after 30 minutes.
6. `createOrder` `POST /orders` — send the `lrs` object with the quote ID, `remittance_information`, and the bank account and beneficiary IDs. `amount` and `currency` (`USD`) must match the quote, and the bank account's bank must match the quote's. A `purpose_code`, if sent, must be `S0001` or `S0002`. Send a `request_id`.
7. **Not an API call:** open Glomo checkout with the Unified SDK, passing the order ID and your public key.
8. **Not an API call:** on your server, verify the signature on the checkout response. Check it against each of your active secret keys; any one matching is valid.
9. **Not an API call:** wait for the `payment` webhook with `event_type` `funds_available`. That, not `success`, tells you the funds have landed.


Full guide: [Collect LRS remittances from India](/payin/resident-india-remittance-under-lrs/set-up)

### Withdrawal

1. `createBeneficiaryV2` `POST /v2/beneficiaries` — use `category: payout`, an INR account and the IFSC in `local_routing_number`. The beneficiary must be `active` before you pay it.
2. `createDocument` `POST /document` — upload the investor's withdrawal consent letter.
3. `createLrsQuote` `POST /lrs/quotes` — optional: with `resource: payout`, an estimate of the INR the investor receives. You cannot attach it to the payout.
4. `createPayout` `POST /payouts` — send `source_currency` `USD`, `destination_currency` `INR`, `source_amount` in USD cents (required), `payment_rail: neft` (if you omit `payment_rail`, Glomo uses SWIFT), purpose code `P0001`, the document ID in `documents`, and a unique `request_id`. A reused `request_id` returns 409.
5. `getPayoutById` `GET /payouts/{id}` — read the status, or take it from the `payout` webhook.


Full guide: [Withdraw an LRS remittance back to the investor](/payin/resident-india-remittance-under-lrs/set-up/withdrawal-flow-guide)

## Fund distribution (Nivo for Distributors)

For distributors who bring investors to a fund's schemes. The investor completes the fund's own journey, and the purchase is made with your ARN. Nivo for Distributors is enabled per business, and Glomo sets up your relationship with each fund. The relationship holds your ARN for that fund and the schemes the fund lets you sell. Only regular-plan schemes can be distributed. Read [Distributor](/capital-markets/distributor) for what the relationship fixes.

### Payment session (one investor)

1. `createPaymentSession` `POST /payment-sessions` — call it from your server. Send the scheme code in `data.scheme.scheme_code`. Optionally prefill `email`, `data.scheme.amount` and `data.scheme.currency` (both or neither, in `USD` cents), and `data.kyc`. `email` is required if you send `pan`, `phone` or `dob`. Do not send `customer_id`; it returns 422. `distributor_arn` is ignored; Glomo uses the ARN from your relationship.
2. **Not an API call:** keep the returned `token` on your server. Do not log it or send it anywhere except the investor's checkout.
3. **Not an API call:** open the session with the Unified SDK, passing `id` as `paymentSessionId` and `token` as `paymentSessionToken`. The investor completes the fund's journey. Your ARN is shown on the checkout and cannot be changed.


Full guide: [Open payment sessions as a distributor](/capital-markets/distributor/set-up)

### Distributor link (many investors)

1. `createDistributorLink` `POST /distributor-links` — call it from your server with `scheme_code`. `amount` (in `USD` cents, within the scheme's limits) is an optional prefill the investor can change. `distributor_arn` is optional; if sent, it must be your ARN for that fund. Distributor links are enabled separately; without them the call returns 400 `Feature not enabled`.
2. **Not an API call:** share the returned `url` with investors. It does not expire, and anyone with it can open it.
3. **Not an API call:** each investor who opens the link gets a new payment session, prefilled with the scheme, your ARN and the amount, and completes the fund's journey.


Full guide: [One Click Distributor Link](/capital-markets/distributor/share-a-link)

## Payouts

For merchants sending money from their Glomo balance to a beneficiary's bank account.

### Calls, in order

1. `createBeneficiaryV2` `POST /v2/beneficiaries` — use `category: payout`, with the bank details that the [rail](/payout/rails) you will use needs. Only INR, AED, EUR, GBP and AUD have local rails: for any other destination currency, USD included, the rail is SWIFT, so the beneficiary needs `swift_code`.
2. `getBeneficiaryByIdV2` `GET /v2/beneficiaries/{id}` — the beneficiary must be `active`. A new beneficiary is `active` straight away unless Glomo has enabled beneficiary review on your account. With review enabled it starts `pending`; in sandbox, approve it with `PATCH /v2/beneficiaries/{id}/mock-review` `{"review_action": "approve"}`. A payout to a `pending` or `rejected` beneficiary is refused. The `beneficiary` webhook reports the change.
3. `createDocument` `POST /document` — only if the purpose code needs documents. Pass the IDs in the payout's `documents`.
4. `createQuote` `POST /quotes` — optional: `resource: payout` fixes the rate and fee. With a `quote_id`, don't send amounts, currencies or `payment_rail` on the payout. A quote expires and can be used once.
5. `createPayout` `POST /payouts` — without a quote, set `payment_rail`: if you omit it, Glomo uses SWIFT, and a beneficiary without SWIFT details gets a 400. With a `quote_id`, sending `payment_rail` is a 400. Send a payout purpose code. Send a deterministic `request_id`: a reused one returns 409, so retry with the same one and never with a new one.
6. `getPayoutById` `GET /payouts/{id}` — read the status. The create call returns 201 even when the payout has already failed. The `payout` webhook reports each change.


Full guide: [Send payouts with the API](/payout/set-up)

## Bank transfer collection

For merchants receiving collections in local currency for their orders by bank transfer. Bank transfer must be enabled on your account. For other bank-transfer flows, such as a static virtual account, confirm the flow with Glomo before you build; they have no documented call sequence yet.

### Calls, in order

1. `createCustomer` `POST /customer` — create the payer once and store the `cust_` ID.
2. `createOrder` `POST /orders` — send a `request_id`. `payment_methods` limits what checkout offers; leave it out to offer every method enabled on your account.
3. **Not an API call:** open Glomo checkout with the Unified SDK, passing the order ID and your public key. The customer picks bank transfer and sees the account details and the payment reference to use.
4. **Not an API call:** handle the checkout's `payment.bank_transfer_submitted` event, or the redirect to your `callbackUrl`. It only means the customer says they sent the transfer.
5. **Not an API call:** take the final status from the `payment` webhook.
6. `getEligiblePayins` `GET /payment/{id}/eligible-payins` — only when the payment is `action_required` with `PAYIN_NOT_FOUND` or `PAYIN_AMOUNT_MISMATCH`: list the payins it can connect to.
7. `connectPayin` `POST /payment/{id}/connect-payin` — connect the payment to one of them. [Resolving Action Required Payments](/payin/action-required) covers the case where none is eligible.


Full guide: [Checkout](/payin/checkout)

## Bank account verification (TPV)

For merchants who must accept funds only from the payer's registered bank account, such as brokers and fund platforms. Glomo enables TPV per account. TPV is the only value-added service documented here; for any other, confirm the flow with Glomo.

### Calls, in order

1. `createCustomer` `POST /customer` — create the payer once and store the `cust_` ID.
2. `createCustomerBankAccount` `POST /customer/{id}/bank-accounts` — register the account the payer will pay from (`account_number` plus `bic_primary` or `bic_secondary`). A customer has one active account; a new one replaces it.
3. `createOrder` `POST /orders` — create the order as usual; it needs no TPV field.
4. **Not an API call:** collect the payment as in [One-time collection](#one-time-collection).
5. **Not an API call:** a bank payment from any other account leaves the payment `action_required`. [Third Party Verification (TPV)](/verification/third-party-verification) lists the mismatch reasons and what to do next.


Full guide: [Verify a payer's bank account (TPV)](/verification/third-party-verification/set-up)

## The rest of the documentation

- **[Glomo overview](/get-started/glomo-overview)** — the platform glossary. What an LRS order, purpose code, virtual account or RFI actually *is*.
- **[Payin](/payin)** — collecting money: customers, orders, checkout, payment links, payment methods, refunds, disputes, subscriptions, LRS.
- **[Payout](/payout)** — sending money: the payout life cycle, rails, beneficiaries, purpose codes.
- **[Nivo (Capital markets)](/capital-markets)** — mutual fund investments: payment sessions for funds and distributors, distributor links, overseas investing and LRS SIP.
- **[Multi-currency accounts](/multi-currency-account)** — holding money: balances, conversion, add and withdraw, and the settlement holiday calendar.
- **[Verification](/verification/kyc)** — KYC, bank account validation and TPV.
- **[Request for Information (RFI)](/request-for-information)** — responding to a compliance request, per object.
- **[Reports](/reports)** — the reports you download or schedule from the dashboard for reconciliation, compliance and treasury.
- **[Identity and Access Management](/access-management)** — one login across your MIDs, the Admin/Member/Sales Partner roles, and inviting your team.
- **[API reference](/api-reference/openapi)** — every endpoint, generated from OpenAPI. The
OpenAPI description itself is published as one self-contained file at
[/openapi.yaml](/openapi.yaml) ([JSON](/openapi.json)) — point your SDK generator, HTTP client or
coding agent at it directly.
- **[Developer resources](/platform)** — authentication, errors, pagination, rate limits, webhooks, versioning, supported countries, quotes and the client SDKs.


## Get your API keys

Every request to the Glomo API carries an API key. You get your keys from the Glomo dashboard.

1. **Log in**: sign in to the [Glomo dashboard](https://app.glomopay.com).
2. **Open API Keys**: go to the [API Keys](https://app.glomopay.com/api-keys-and-webhooks/api-keys) page to see your **Test** and **Live** keys.
![API Keys Section](/assets/api_keys.5e6788b98d66acc8f93a1ddea725fb2144aa439e116f764793764594d91aa3de.9c1bb791.svg)
3. **Choose your environment**:
  - **Test**: use test keys to simulate transactions without real money.
  - **Live**: switch to live keys when you are ready to process real payments.
4. **Integrate**: see [Authentication](/platform/authentication) for how to send the key on every request, then follow the section for your integration above.