EcashPay API

EcashPay is a payment gateway for the Philippines. You create a payment over HTTPS, naming how the customer pays — a credit card, a debit card, QR, or an e-wallet — we charge it on whichever rail currently serves that method, and you read the result back from the same API.

With one integration you can:

• Charge a customer through a checkout page we host, or directly on a rail you name.
• Refund in full or in part, and capture or cancel a payment you authorized earlier.
• Read your own ledger — every transaction, filtered and paginated, with its event timeline and refunds.
• Read your payer directory — who paid you, how often, and how much.

Everything above is one API and one credential. There is no separate reporting API and no second key to manage.

A payment has one lifecycle whichever rail it travels on. Your server starts it, your customer completes it somewhere else, and your server confirms it:

1. Your server calls POST /v1/payments with a method, an amount, a customerEmail and your own order reference — all four are required. We answer with a payment id, a status of PENDING, and either a paymentLinkUrl or — for a QR payment — a qrString, never both.
2. You send the customer to that URL, or render the qrString we returned as a QR code — a QR payment carries no link.
3. The customer pays. The payment service tells us, we verify what they sent and move the payment to its final status.
4. The customer comes back to your successReturnUrl, and your server asks GET /v1/payments/:paymentId what actually happened.

Step four is not optional, and it is the step most first integrations get wrong. A customer landing back on your site is not proof of payment — Confirming the outcome explains why, and what to do instead.

Every endpoint is served under your deployment's API base URL, followed by a version segment that belongs to the endpoint rather than to the API as a whole:

Store the part before the version — https://be.ecashpay.com/api — and let each path contribute its own /v1. Endpoints are versioned one at a time: when a single operation makes a breaking change it is published at /v2 beside its /v1 twin, and everything else stays where it is. A client that hard-codes /v1 into its base URL has to be edited on that day; one that follows the paths in the reference does not.

Responses are JSON and always wrapped in the same envelope, with a request id you can quote to support. Errors covers both.

• New here? Quickstart takes you from an empty account to a paid test transaction.
• Writing the client? Signing requests is the part you cannot skip, and it has a complete working client at the bottom.
• Looking for a field? The API reference is generated from the live API.
• Ready to charge real money? Create an account.