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:
| Actor | Makes payment links? | Receives money? |
|---|---|---|
| Customer | No | No — they pay |
| Merchant | Yes, via merchant dashboard | Yes — directly to their own wallet |
| Partner | Yes, via API key, on behalf of their merchants | No — no access to merchant wallets |
| JoPay | Yes, via admin (on behalf of anyone) | No — non-custodial, never holds funds |
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
- Partner = the software platform. They provide the UX, branding, and automation.
- Merchant = the seller / service provider. They receive the money, directly, in their own wallet.
- JoPay never touches the money. It only issues instructions and verifies on-chain transfers.
- Metadata is the glue. It lets the partner’s system correlate JoPay’s
request_idto their ownorder_id,ticket_id,invoice_number, orbooking_idwithout 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 case | How merchants are created |
|---|---|
| Shopify / WooCommerce plugin | Each shop owner completes the JoPay merchant onboarding manually. Plugin stores the resulting merchant_id in WP/Shopify settings. |
| POS / restaurant | One-time onboarding at POS installation, typically done by the partner’s customer success team. |
| Marketplace / freelance | Host / freelancer onboarding at signup — a redirect into JoPay’s merchant flow, then back. |
| SaaS self-billing | One 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. |
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.