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.

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 or in /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 and one for payouts. Pick from the list; never guess a code.

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.

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

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

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

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.

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

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

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.

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

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

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

1. createBeneficiaryV2 POST /v2/beneficiaries — use category: payout, with the bank details that the rail 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

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.

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 covers the case where none is eligible.

Full guide: Checkout

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.

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.
5. Not an API call: a bank payment from any other account leaves the payment action_required. Third Party Verification (TPV) lists the mismatch reasons and what to do next.

Full guide: Verify a payer's bank account (TPV)

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

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.

2. Open API Keys: go to the API Keys page to see your Test and Live keys.

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 for how to send the key on every request, then follow the section for your integration above.