Integrations

Three ways in, and we will not pretend there are more

There is a REST API, there are signed webhooks, and there are hosted payment links. That is the complete set. A wall of platform logos with no connector behind them is an invitation to click something that does nothing.

The paths

Pick by how much you want to build

No code

Hosted payment links

Create a link in the dashboard and share it. The payer gets a page with a QR, the exact amount, a countdown and live status. Works in an email, a chat message, or printed as a QR on an invoice.

  • Nothing to deploy
  • Works for one-off invoices and standing donation links
  • A return URL sends the payer back to you when they are done
How links work
A backend

REST API

Create payment requests from your own server with an API key. Four endpoints: create, list, retrieve, cancel. Amounts are decimal strings, and the key is a bearer token.

  • Server to server, no customer credentials involved
  • 120 requests a minute
  • A separate public endpoint if you want to render your own checkout
API reference
A receiver

Signed webhooks

Set a webhook URL on a payment request and we POST a signed JSON body when it settles, arrives late, or expires. Verify the HMAC over the raw body before you act on it.

  • Three events, and no others
  • Retried up to six times with backoff
  • Deliveries and status codes visible in your dashboard
Webhook reference

What does not exist yet

There are no platform plugins

No Shopify app, no WooCommerce plugin, no Magento extension, no accounting connector. If you are on one of those platforms, the integration is the API — someone on your side writes it, or you use hosted links and reconcile manually.

What building one looks like

Smaller than it sounds. A working integration is one POST, one page redirect and one signed callback — a few hours for someone who knows the platform's checkout hooks.

  1. 1 At checkout, POST a payment request with the order total and your order id as the reference.
  2. 2 Send the customer to the hosted page you get back, or render your own from the public JSON.
  3. 3 On payment.paid, match on your reference and mark the order paid. Make it idempotent — a delivery can repeat.
  4. 4 On payment.expired, release the basket. On payment.late, decide by hand.

What you get instead of a plugin

  • A dashboard that shows the deliveries

    Recent callbacks with their status codes, so a receiver that is quietly returning 500 is findable in seconds rather than by guesswork.

  • A public JSON view of any request

    The same data the hosted page renders, unauthenticated, so you can build a checkout that matches your own product.

  • Docs that match the code

    Every endpoint, parameter and error shape on the reference page is taken from the routes this application actually serves.

  • People who wrote it

    If the API is missing something your platform needs, that is a useful thing for us to hear rather than a support ticket to deflect.

At a glance

Everything you can call

Merchant API

https://cryptogate.foundrcode.com/api/merchant/v1
POST /payment-requests Create an invoice or a donation link
GET /payment-requests List yours, newest first, paginated
GET /payment-requests/{id} Retrieve one
POST /payment-requests/{id}/cancel Close one early

Public, unauthenticated

GET The payer view as JSON
https://cryptogate.foundrcode.com/api/pay/{slug}
GET The hosted checkout page
https://cryptogate.foundrcode.com/pay/{slug}

Webhooks out

payment.paid Settled in full. Fulfil on this one.
payment.late Paid after expiry. Credited, but worth a look.
payment.expired Window closed. Any partial amount is stated.

Tell us what you are building on

If enough people need the same connector, that is how it gets built. And if the API is missing a field you need, say so.