REST API

Payment Links API

Create, list, and manage shareable payment links programmatically. A payment link is a hosted URL where customers pay by card — create one once and reuse it, or issue a fresh link per invoice.

Required scopes#

EndpointScope
List / Get payment linkspayment_links:read
Create / Cancel payment linkspayment_links:write
Create payment link from invoicepayment_links:write

Checkout identifiers#

Append query parameters to a payment link URL to identify the payer. Only these are accepted (all others are silently ignored): client_reference_id, customer_email, customer_id, customer_name. They are stored with the payment and returned as top-level fields in the payment_link.paid and payment_link.payment_settled webhooks (always present, set to null when not supplied). Each webhook carries the identifiers of the payment that triggered it, so a reusable link that has taken several payments still reports the right payer on every event.

Privacy — these are payer-modifiable
These parameters are passed via the URL and can be modified by the payer. Safe for identifying who is paying — never use them to authorize actions on your side. Fields like customer_email and customer_name are visible in browser history, server logs, and shared links; prefer opaque identifiers. Passing email or name is opt-in PII exposure with possible compliance implications (GDPR/CCPA). To tie a payment to an order, use a dedicated link per order and the server-side payment_reference field.

Returning customers to your mobile app#

After a successful payment, the customer briefly sees the hosted confirmation page and is then redirected to the URL configured in redirect_url. The redirect is client-side: HTTPS URLs route through the browser, custom-scheme URLs route through the OS deep-link handler. If redirect_url is omitted, the customer stays on the hosted success page instead.

If the customer paid inside your mobile app — an in-app browser or a system browser launched from the app — there are three options for redirect_url, best to worst:

  1. Universal Link / App Link (recommended). A plain HTTPS URL on your own domain that the OS routes to your installed app, falling back to the web if it isn't installed. Configure apple-app-site-association (iOS) and assetlinks.json (Android) on the same domain — one URL works on mobile and desktop, with no broken-redirect failure mode.
  2. Dispatcher page on your own domain. An HTTPS URL that runs JavaScript on load to redirect to your app's custom scheme, falling back to the App Store or Play Store when no scheme handler fires.
  3. Custom app scheme directly. A URL like myapp://payment-success that the OS hands to your installed app. Works only if the app is installed; in-app browsers (Facebook, Instagram, some mail clients) may silently swallow it with no fallback.
Schemes rejected for security
The API accepts all three forms in redirect_url, but always rejects http, javascript, data, file, vbscript, about, and blob schemes. Always treat the payment_link.paid webhook — never the redirect arriving — as the canonical fulfillment signal: deep links can be swallowed by in-app browsers, and custom schemes fail when the app isn't installed.

Immutability & status#

Payment links are intentionally immutable after creation — you cannot change the amount, currency, link type, or account. For different terms, cancel the link and create a new one. This keeps an already-shared URL a consistent commitment.

The API can only cancel links. Marking a link paid happens exclusively through the card payment flow (a webhook from the payment processor), never via the API — this prevents payment fraud by requiring actual payment verification. Set link_type: "reusable" with max_payments to accept multiple payments; the link auto-expires once the count is reached.

Recurring billing#

Manza does not auto-charge stored cards. Your application schedules a fresh payment request each billing period, and the customer authorizes each payment. Follow the Recurring billing guide for the full workflow, approval options, reminders and webhook reconciliation.

Error responses#

ScenarioStatusTypeParam
Invalid account_id422validation_erroraccount_id
Amount ≤ 0422validation_erroramount
Amount below 10 MAD minimum422validation_erroramount
Invalid redirect_url422validation_errorredirect_url
Cancel non-active or expired link422state_error—
Invoice already has payment link422validation_errorinvoice_id
expires_at in the past422validation_errorexpires_at
Payment links not enabled403forbidden_error—