API Validations

Glomo APIs apply comprehensive business logic validations to ensure that every request aligns with product rules, regulatory standards, and expected workflows. These validations go beyond simple formatting checks and focus on the correctness, consistency, and legitimacy of the transaction itself. By enforcing these rules, Glomo guarantees that only valid operations are processed, while any invalid request is immediately rejected with a clear and standardized error response.

Validations for creating customers

Field	What Can Go Wrong	Error Message You'll See
Name	Missing or blank	Customer name cannot be blank.
Customer Type	Anything other than Individual or Business	Customer type must be either Individual or Business.
Email	Wrong format	Email address is not valid.
Email	Already used in your business	This email address is already registered under your business.
Phone	Wrong format (if provided)	Phone number format is invalid.
Address	Missing	Address cannot be blank.
City	Missing	City cannot be blank.
State	Missing	State cannot be blank.
Country	Wrong code (not 3-letter, lowercase, or unsupported)	Country code must be a valid 3-letter ISO code (e.g., IND, USA).
Pincode	Missing for countries where it is mandatory	Pincode is required for the selected country.
Nationality	Wrong code (not valid 3-letter ISO)	Nationality code must be valid 3-letter ISO.
Date of Birth	Future date or wrong format	Date of birth must be in the past.
Duplicate Customer	Email already exists in the system	A customer with this email already exists.

Note: By default, customer uniqueness is enforced on email — a business cannot create two customers with the same email. On the LRS flow, this can instead be enforced on PAN (tax_identification_number) in place of email, so customers are de-duplicated by PAN even if they use different emails. This is off by default — to enable it for your account, reach out to support@glomopay.com.

Validations for updating customers

Applies to PATCH /customer/{id}. Only email and phone can be updated, and the update is partial — omitted fields are left unchanged.

Field	What Can Go Wrong	Error Message You'll See
Customer ID	Missing, empty, or wrong format (must start with cust_)	Customer ID must start with cust_ and be valid.
Request	Neither `email` nor `phone` supplied	At least one field must be provided to update.
Email	Supplied but blank or `null`	Email can't be blank.
Email	Wrong format	Email address is not valid.
Phone	Supplied but blank or `null`	Phone can't be blank.
Phone	Not a valid number for the customer's country	Phone number format is invalid.
Customer Not Found	Customer ID doesn't exist in your account	Customer not found.

Validations for creating orders

Field	What Can Go Wrong	Error Message You'll See
Customer ID	Missing, empty, or wrong format (must start with cust_)	Customer ID must start with cust_ and be valid.
Amount	Zero, negative, or non-integer	Amount must be a positive whole number in the smallest currency unit (e.g., cents).
Currency	Not supported or not uppercase 3-letter code	Currency code must be valid (USD, EUR, GBP, AED, SGD).
Document ID	Wrong format (must start with doc_)	Document ID must start with doc_ and be valid.
Purpose Code	Invalid or not found in the system	Purpose code is not valid.
Invoice Amount	Zero or negative	Invoice amount must be greater than 0.
Invoice Number	Contains unsupported characters or too long (>50 chars)	Invoice number contains invalid characters or is too long.
Invoice Description	Contains unsupported characters or too long (>512 chars)	Invoice description contains invalid characters or is too long.
Product (Name/Description)	Name missing, invalid characters, or too long	Product name is required, valid characters only, max 128 chars.
Notes / Reference Number	Wrong format (rare)	Notes or reference number is invalid.
Duplicate Order	Order already exists	An order with these details already exists.
Customer Not Found	Customer ID doesn't exist in your account	Customer not found.

Validations for creating payment links

Field	What Can Go Wrong	Error Message You'll See
Customer ID	Missing, empty, or wrong format (must start with cust_)	Customer ID must start with cust_ and be valid.
Amount	Zero, negative, or non-integer	The amount must be a positive whole number in the smallest currency unit (e.g., cents).
Currency	Not supported or not uppercase 3-letter code	Currency code must be valid (USD, EUR, GBP, AED, SGD).
Purpose Code	Invalid or missing	Purpose code is not valid.
Expires At	Past date, wrong format, or more than 6 months ahead	Expiry date must be in the future and within 6 months.
Document ID	Wrong format (must start with doc_)	Document ID must start with doc_ and be valid.
Invoice Amount	Zero or negative	Invoice amount must be greater than 0.
Invoice Number	Contains unsupported characters or too long (>50 chars)	Invoice number contains invalid characters or is too long.
Invoice Description	Contains unsupported characters or too long (>512 chars)	Invoice description contains invalid characters or is too long.
Reminder Frequency	Value not in [1, 2, 7, 14]	Reminder frequency must be 1, 2, 7, or 14 days.
Product (Name/Description)	Name missing, invalid characters, or too long	Product name is required, valid characters only, max 128 chars.
Reference Number	Wrong format (rare)	Reference number is invalid.
Customer Not Found	Customer ID doesn't exist in your account	Customer not found.
Document Not Found	Document ID doesn't exist in your account	Document not found.
Duplicate Payment Link	Link already exists	A payment link with these details already exists.

Validations for declaring dynamic fee splits

Applies to POST /prices/dynamic-splits. List the rules you may declare against with GET /prices/dynamic.

Field	What Can Go Wrong	Error Message You'll See
Price ID	Missing or blank	Price id can't be blank
Price ID	Wrong format (must start with price_)	Price id must start with 'price_' and contain only alphanumeric characters
Price ID	Does not exist, or belongs to another business	price_id not found
Price ID	The rule's fee bearer is not dynamic	price_id is not a dynamic-bearer rule
Price ID	The rule does not price a payin	dynamic splits are only supported for payin
Price ID	The rule does not price transaction fees	dynamic splits are only supported for transaction_fees
Price ID	The rule version is not effective yet	price_id is not effective yet
Price ID	A newer version of the rule is effective	price_id has been superseded by a newer version of the rule
bps / fixed_amount	Neither provided, or both provided	exactly one of bps or fixed_amount must be provided
bps	Missing on a percentage-priced rule	bps is required for a percentage-priced rule
bps	Greater than the rule's own bps	bps cannot exceed the rule's total of 300
fixed_amount	Missing on a fixed-priced rule	fixed_amount is required for a fixed-priced rule
fixed_amount	Greater than the rule's own fees_amount	fixed_amount cannot exceed the rule's total
fee_currency	Does not match a fixed-priced rule's currency	fee_currency must be USD to match the rule
fee_currency	Missing while min_fee or max_fee is declared	fee_currency is required when a bound is declared
min_fee / max_fee	Declared on a fixed-priced rule	min_fee and max_fee are not supported for a fixed-priced rule
min_fee / max_fee	min_fee greater than max_fee	min_fee must be less than or equal to max_fee
Any amount	Not an integer, or negative	Bps must be an integer / Bps must be greater than or equal to 0

Note: All amounts are in minor units (cents) and bps is basis points, so 100 is 1%. A bps of 0 is valid and means the customer bears the whole fee. Each rule is held to its own ceiling — a declaration against one rule is never capped by another rule's total.

Validations for using split_ids

Applies to POST /payin, POST /orders, POST /quotes, POST /subscriptions and POST /payment. Messages raised by form validation arrive prefixed with Validation failed: .

Field	What Can Go Wrong	Error Message You'll See
split_ids	An id does not exist, belongs to another business, or no longer points at a live dynamic rule	Split ids are invalid or no longer point at a dynamic rule: psplit_7Kq2mXbTdLp9
split_ids	Two dynamic rules share a dimension and only one is declared	Split ids must be declared for every dynamic rule on the dimension, missing rules: price_Kd82nvQ1TzAe
split_ids	A declared payment method is not enabled for your business (payment links and orders only)	Split ids are not valid for any enabled payment method: bank_transfer
split_ids	Omitted while your account requires a declaration	Split ids are required when dynamic fee splits are enforced
split_ids	Sent with a quote_id on a payment link or an order	Split ids cannot be specified when quote_id is present
split_ids	Sent on a quote whose resource is not payin	split_ids is only valid for payin quotes
split_ids	Sent on a fixed-frequency subscription	Split ids are only supported for as_presented subscriptions
split_ids	Sent on `POST /payment` for a fixed-frequency subscription	split_ids are only supported for as_presented subscriptions
split_ids	Omitted on an auto debit whose subscription declaration no longer resolves	Declared fee splits on the subscription no longer point at a live dynamic rule: psplit_7Kq2mXbTdLp9. Pass a valid split_id to override.
split_ids	Declared for a payment method a subscription never charges (only `card` and `pay_via_bank` are chargeable)	Split ids cannot be declared for a payment method a subscription never charges: bank_transfer
split_ids	Sent on an auto debit for a method other than the one the subscription charges	split_ids must be declared for card, which this subscription charges, not bank_transfer

Note: A dimension is the combination of payment method, subtype, rail, currency and fee type. When two dynamic rules share one, declare a split for both.

Note: A subscription only ever charges card, or pay_via_bank when SEPA-eligible, so a split declared for any other payment method is rejected both at subscription creation and on an auto debit. An auto-debit override must be declared for the method the subscription actually charges.

Note: split_ids and payment_methods are independent. payment_methods restricts which methods the checkout offers; a split only changes how the fee for its own payment method is priced. One checkout can price one method from a dynamic split and another method from your normal rules.

Note: If a payment link or an order carries a declaration that no longer resolves, opening the checkout returns 400 Bad Request with This payment_link has expired because of expired split_ids. Please create another payin. (or This orders has expired… for an order). The payin is expired and you must issue a new one.

Validations for creating beneficiaries (v2)

Field	What Can Go Wrong	Error Message You'll See
Category	Missing or blank	Category can't be blank
Category	Not "lrs" or "payout"	Category must be one of: lrs, payout
Beneficiary	Missing or blank	Beneficiary can't be blank
Beneficiary	Not an object	Beneficiary must be an object
Beneficiary Name	Missing or blank	Beneficiary name is required
Beneficiary Address	Missing or blank	Beneficiary address is required
Bank Account	Missing or blank	Bank account can't be blank
Bank Account	Not an object	Bank account must be an object
Account Number	Missing or blank	Bank account account_number is required
Bank Name	Missing or blank	Bank account name is required
SWIFT Code	Missing or blank	Bank account swift_code is required
SWIFT Code	Not 8-11 characters (payout category)	Swift code must be 8 to 11 characters long
SWIFT Code	Not exactly 8 characters (LRS category)	Swift code must be 8 characters long
SWIFT Code	First 6 characters not alphabets	Swift code First 6 characters must be alphabets
SWIFT Code	Country code doesn't match bank address country	Swift code Country code in BIC does not match selected country
Currency	Missing or blank	Bank account currency is required
Bank Address	Missing or blank	Bank account address is required
Local Routing Number	Missing for LRS category	Local routing number can't be blank
Intermediate Bank	Provided but not an object	Bank account intermediate_bank must be an object
Intermediate Bank SWIFT Code	Missing for LRS category	Bank account intermediate_bank swift_code is required for LRS beneficiaries
Duplicate Account	Account already exists for this business	Business already had this Account Number, Account Type and Transfer Method