Partner Use Cases

Ten concrete integration patterns. Each shows the partner role, the merchant role, and how the money flows.

Who does what

JoPay’s role hierarchy is consistent across every integration:

ActorMakes payment links?Receives money?
CustomerNoNo — they pay
MerchantYes, via merchant dashboardYes — directly to their own wallet
PartnerYes, via API key, on behalf of their merchantsNo — no access to merchant wallets
JoPayYes, via admin (on behalf of anyone)No — non-custodial, never holds funds
The partner has the authority to instruct JoPay on behalf of their merchants. The merchant has sole access to their own money. JoPay never holds funds at any point.

Ten use cases

Each example below maps the same three layers. The API surface used is always the same v1 API —see the Developers docs.

1. White-label crypto PSP for emerging markets

Partner: TransFi, Bitso Business, or a regional equivalent.
Merchant: Colombian restaurants, Mexican hotels, Kenyan shops.

The partner runs a merchant dashboard on their own domain. When a merchant clicks “generate QR” the partner’s server calls POST /api/v1/requests/create with the merchant’s id and amount. The pay page opens in the partner’s branding. Money lands in the merchant’s wallet, never in the partner’s.

2. Shopify plugin for crypto checkout

Partner: a plugin developer (“CryptoMate for Shopify”).
Merchant: every Shopify shop that installs the plugin.

Customer clicks “pay with crypto”. Shopify webhooks fire the plugin; the plugin calls JoPay’s create API with the shop’s merchant_id and metadata: { shopify_order_id: "..." }. The webhook returns with the same shopify_order_id, so the plugin marks the Shopify order as paid. No mapping table required on the plugin side.

3. WooCommerce / WordPress plugin

Partner: WooCommerce plugin vendor.
Merchant: 50,000 WooCommerce shops.

Same pattern as Shopify but via WordPress hooks. Each shop stores their JoPay merchant_id in WP admin. The plugin code is the same five API calls (create, webhook listener, optional GET for reconciliation).

4. Freelance marketplace with direct payouts

Partner: the platform (Upwork / Fiverr-style).
Merchant: each freelancer.

Client pays for a job. The platform’s server creates a JoPay request for the freelancer with metadata { job_id, client_id }. Money lands directly in the freelancer’s wallet — the platform never holds funds. Platform fees come from an on-chain split (coming later) rather than from custody.

5. Point-of-sale / restaurant POS integration

Partner: the POS vendor (Lightspeed / Toast-style).
Merchant: each restaurant running the POS.

Server taps “pay with crypto” on the POS tablet. The tablet calls JoPay, shows the QR on the customer-facing screen. Customer scans, pays, webhook fires back, POS prints the receipt. Merchant never leaves the POS app.

6. Ticketing / events platform

Partner: Eventbrite-like ticket platform.
Merchant: each event organiser.

Fan buys a festival ticket. Platform server creates a JoPay link with metadata: { ticket_id, event_id }. Customer pays, webhook triggers e-ticket delivery. Funds go directly to the organiser’s wallet — platform doesn’t hold ticket revenue.

7. Subscription billing for SaaS

Partner: SaaS company (or their billing tool).
Merchant: the SaaS company itself.

First of the month: a cron job calls the JoPay create API for each active subscriber, emails them the pay_page_url. Webhook extends the subscription on verified payment. For this case, partner and merchant are often the same entity — one company using JoPay as their billing rail.

8. B2B invoicing software

Partner: invoicing tool (Moneybird / Exact / FreshBooks style).
Merchant: every MKB user of the tool.

User creates an invoice, ticks “accept crypto”. The software calls JoPay with metadata: { invoice_number }. The pay link is embedded in the invoice PDF. Customer clicks from email, pays, webhook marks the invoice as paid in the accounting software.

9. Booking marketplace (Airbnb-style)

Partner: the marketplace.
Merchant: every host / property owner.

Guest books a stay. Marketplace creates a JoPay link for the host with metadata: { booking_id, check_in_date }. Funds flow directly to the host’s wallet at the agreed time — in the future via an on-chain escrow contract that releases on check-in.

10. WhatsApp / Telegram bot for local sellers

Partner: a bot platform serving local shopkeepers (especially in Africa / Southeast Asia).
Merchant: the shopkeeper.

Shopkeeper types “pay link for 25 euro to Jan” in WhatsApp. The bot calls JoPay’s create API, receives the URL, replies in the chat. Shopkeeper forwards the link to Jan. Jan pays, funds arrive in the shopkeeper’s wallet.

What they all have in common

  1. Partner = the software platform. They provide the UX, branding, and automation.
  2. Merchant = the seller / service provider. They receive the money, directly, in their own wallet.
  3. JoPay never touches the money. It only issues instructions and verifies on-chain transfers.
  4. Metadata is the glue. It lets the partner’s system correlate JoPay’s request_id to their own order_id, ticket_id, invoice_number, or booking_id without maintaining a mapping table.

Where they differ

The hardest part of each integration is merchant onboarding. How does a merchant get a JoPay merchant id and wallet in the first place? Today this differs per case:

Use caseHow merchants are created
Shopify / WooCommerce pluginEach shop owner completes the JoPay merchant onboarding manually. Plugin stores the resulting merchant_id in WP/Shopify settings.
POS / restaurantOne-time onboarding at POS installation, typically done by the partner’s customer success team.
Marketplace / freelanceHost / freelancer onboarding at signup — a redirect into JoPay’s merchant flow, then back.
SaaS self-billingOne merchant (the SaaS company itself). Set up once by a JoPay admin.
PSP / payment aggregator (Mollie-like)Now supported via POST /api/v1/merchants. Create a shell merchant, receive an onboarding_url, redirect the user to finish wallet setup and TOS acceptance in JoPay’s flow. Test mode and restricted-scope keys are still on the roadmap.
Programmatic merchant creation is now supported via POST /api/v1/merchants. PSP-style integrations (Mollie, Adyen-class aggregators) can provision merchants server-to-server and redirect users to onboarding_url to finish setup. Test mode (jo_test_* keys with sandbox isolation) and restricted-scope keys are still on the roadmap — see Developers / Authentication.

Next steps

  • Read the Developers docs to see the exact endpoints, auth, and webhook events.
  • See the webhook guide for how to handle verified payments.
  • Ask a JoPay admin to provision a partner account — self-serve partner signup isn’t open yet.