Merchant Payment Link

Overview

A merchant payment link is a shareable URL created by a merchant to collect a fixed or variable payment without building a complete checkout integration. The link opens a provider or merchant page that presents the recipient, amount or input rules, supported methods, and payment status. A reusable link must still create unique payment sessions so different customers and transactions can be reconciled independently.

Important risks include phishing, parameter tampering, outdated prices, duplicate orders, unauthorized sharing, leaked customer context, and browser success treated as settlement.

Systems should store merchant and link IDs, configuration, generated sessions, customer reference, amount, payment attempt, authoritative status, and fulfillment.

For Merchant Payment Link, the operational boundary with Shareable Payment Link and OxaPay Payment Link should be explicit. Identifiers for Merchant Payment Link should connect those records without allowing either linked status to overwrite its own state.

For Merchant Payment Link, a payment link should resolve to a server-controlled payment object rather than storing trust in the URL itself. When Merchant Payment Link interacts with Shareable Payment Link, the link or token identifies the request, while the backend supplies the current amount, currency, accepted assets, network choices, lifetime, merchant identity, and status. In the relationship between Merchant Payment Link and OxaPay Payment Link, signed or high-entropy identifiers, HTTPS, expiration, and access controls reduce guessing, tampering, and unintended reuse.

For Merchant Payment Link, shareability and reusability must be defined explicitly. When Merchant Payment Link interacts with Shareable Payment Link, a single-use link should reject or safely reconcile repeated attempts, while a reusable link needs a rule for creating separate payment sessions and associating each payer or order. In the relationship between Merchant Payment Link and OxaPay Payment Link, links embedded in email, chat, social media, or QR codes should be treated as public and must not contain API secrets or sensitive customer data.