Payments move money, so MaruPay is built to make wrong outcomes hard: a payment completes only on confirmed receipt, every result we send is signed, and settlement records aren't rewritten. This page describes the practices behind that and what we ask of merchants in return.
Payment integrity
- A payment completes only when receipt is confirmed. A user saying they've paid doesn't complete it.
- A confirmed receipt is attached to a payment only when exactly one payment request matches. No match or several matches send it to review, where an operator decides.
- Create requests carry an Idempotency-Key, so a retried request can't create a second payment.
- Settlement records are append-only. Corrections are added as new entries, so the history stays intact.
- Live payments open only after a merchant's integration passes the integration test.
Signed webhooks
- Every webhook carries a signature: an HMAC-SHA256 over a timestamp and the raw request body, made with a secret unique to your endpoint.
- Receivers should reject events whose timestamp falls outside a short tolerance window, which limits replay.
- Signing secrets can be rotated from the console.
- Failed deliveries are retried on a backoff, and any event can be redelivered. Each event keeps the same ID across retries so it can be applied once.
API access
- API requests are authenticated with account-specific keys and must use TLS.
- Keys can be rotated from the console, so you can replace a key without contacting us.
- An optional IP allowlist limits API use to addresses you choose.
Console access
- Console access is limited to approved merchant accounts.
- Two-factor sign-in is available to every user, and account owners can require it for their whole team.
- Roles let you give each teammate only the access their work needs.
How we operate
- Access to production systems is limited to the people who operate them and follows least privilege.
- Operator decisions on payments in review are recorded with who made them and when.
- Data in transit is encrypted with TLS. Production data is kept in managed databases with restricted network access and regular backups.
- If an incident affects your account or data, we'll notify you without undue delay and share what we know.
What we ask of merchants
- Verify the signature of every webhook before acting on it, and apply each event ID once.
- Keep API keys and webhook secrets on your servers, never in client-side code or repositories.
- Turn on the IP allowlist and require two-factor sign-in for your team.
- Rotate keys and secrets when team members leave or a secret may have been exposed.
Reporting a vulnerability
If you believe you've found a security issue, email us with the details and steps to reproduce it. Please don't access data that isn't yours, degrade the service or disclose the issue publicly before we've had a chance to fix it. We'll acknowledge your report and keep you updated.
We don't list certifications on this page. If your review requires specific security documentation, raise it during the merchant review.
Questions about this page?
Contact us: [email protected]