Skip to main content
Every other endpoint in this reference acts on behalf of one of your customers, identified by the customer-id header. These two do not: they answer for your own merchant account.
These endpoints must not carry a customer-id header. Sending one returns a 400 rather than quietly answering for that customer, so you can never mistake a customer’s balance for your own.

​
Your money vs your customers’ money

Your customers hold their own wallets: the funds they deposit, and the amounts locked in open escrows. That money is theirs, and it is never counted in your balance. Your merchant wallet holds what Payluk has settled to you: See Fees and settlement for how each is calculated.

​
Endpoints

​
Which endpoint do you want?

Your own money

GET /v1/merchant/balance and GET /v1/merchant/transactions. No customer-id header.

A customer's money

GET /v1/wallet and GET /v1/payment/history. Both require the customer-id header.

​
Pagination and filters

GET /v1/merchant/transactions behaves exactly like Get payment history: paginated by default, and a flat array the moment you supply reference, fromDate, or toDate. See Pagination.
To reconcile a single settlement, filter by its reference. To close off a period, pass fromDate and toDate and read the flat array straight through.

​
Keeping in step with webhooks

Both earnings types also arrive as webhooks the moment they settle: payment.commission.success and payment.delivery.success. Treat the webhook as the trigger and these endpoints as the source of truth, rather than polling for a balance change. See Webhooks.