Payment links, widget & checkout
Let customers pay you without an invoice.
Payment links
A payment link is the fastest way to collect money without an invoice. You create a link, send it, and the customer pays on a secure hosted page.
- 1Go to Accept Payments → Payment Links and click New Payment Link.
- 2Set an amount, or leave it at $0.00 to let the customer choose how much to pay. You can add an invoice number, an expiry (default 30 days), a description, and the customer's name, email, and phone.
- 3Click Create Link. Then send it: Copy URL to paste into an email or chat, or click Text to send the link straight to the customer's phone.
- 4The link locks after the first successful payment, so it can't be paid twice. You can cancel a link any time, and the board shows each one as Pending, Paid, Cancelled, or Expired.

Text a link for the fastest pay: the customer's saved phone fills in, and the SMS is STOP-compliant like every Merchant360 text. Leave the amount open for a tip jar or a donation.
The pay widget & your hosted pay page
The pay widget gives you two things: a hosted pay page at your own link that you can share or preview, and an embeddable form you can drop onto your own website so customers pay without leaving your site.
Go to Accept Payments → Pay Widget and activate it (this needs card processing to be active). Then set it up:
- 1Master switch: turn payments on or off. While off, visitors see a "payments aren't available" notice.
- 2Payment types: choose what the page accepts – a fixed amount, donations, save a card on file, pay an invoice, or subscriptions.
- 3Amount range: set a Minimum and Maximum. These are enforced on the server, so no one can tamper with the link or request to pay outside the range.
- 4Branding and receipts: set your brand color and the from / BCC email for receipts (your logo comes from your business profile).
- 5Embed: copy the snippet and paste it into your website. It renders a secure form pointed at the processor, so no card data ever touches your site.
- 6Pay Now button: use the button generator to build a ready-to-paste button – set the text, an optional amount and description, then pick a color, size, and corners. Copy the button HTML for your website or email, or just copy the plain link and point any button you already have at it. Leave the amount blank to let the customer enter it. Choose how it opens: a new page, or a popup right on your site so the customer never leaves your page. Set a Success URL to send the customer to your own thank-you page after they pay – the popup closes and redirects there; leave it blank to show the receipt with a Close button.

Copy your public pay-page URL to share it directly, or use Preview to see exactly what a customer sees before you send it out.
What your pay page can accept
The Pay Widget is one tool that changes shape based on which payment types you turn on. Each type below is a different way to collect – mix and match them, or run just one.
- 1Fixed amount – you set the price (via the embed's amount, or the amount range) and the customer just pays it. Best for a product, a booking, or a set fee.
- 2Donations – the giver picks the amount, from preset chips or a custom value. Best for nonprofits, tips, and pay-what-you-want.
- 3Save a card on file – no charge; the customer's card is securely vaulted for a future invoice or subscription.
- 4Pay an external invoice – the customer types your own invoice number and the amount, and pays it. Best when your invoices live in QuickBooks, Xero, or another system.
- 5Pay a Merchant360 invoice – the customer looks up an invoice you sent from Merchant360 (by their email and customer code), sees the balance, and pays it. No link needed – they can find it themselves.
- 6Subscriptions – the customer enrolls in a recurring plan you've set up (weekly, monthly, and so on) and the card is billed automatically.

Turning on more types doesn't clutter the page – the widget shows only what fits the link a customer opens.
API keys for developers
If you build your own website or app, you can issue an API key from the pay widget for server-to-server charges. Issue a key, re-issue to rotate it, or revoke it. The full key is shown only once, so save it when it's created.
The embedded widget and hosted pay page don't need the key: they authenticate through the snippet itself. The key is only for direct server-to-server calls.
Verify a payment on your thank-you page: when a Pay Now button sends the customer to your Success URL, we add ?m360_ref=... to the address. From your server (never the browser – the key is a secret), call GET /api/cygma/v1/verify?reference=<that value> with your API key in the Authorization header. It replies whether the payment truly cleared, with the amount and card last 4, so you can confirm the order before showing a receipt. Treat the redirect itself as a hint; this check is the proof.
Developer checkout (hosted sessions)
Checkout (Accept Payments → Checkout) is for developers building payments into their own site or app. Instead of a drag-and-drop page builder, you create a secure checkout session through the Merchant360 API and send the customer to a hosted pay page; card details never touch your site.
The page gives you Get API keys, the API docs, and a Try the demo link, plus a list of every checkout session (amount, description, customer, and status: open, complete, or expired). If you just want a no-code way to collect a payment, use a payment link or the pay widget above instead.

What your customer sees on the hosted checkout
Every checkout session opens the same secure page: your logo and business name up top, the order summary on the left, and the payment form on the right. It's the page behind the Payment Extension's "Open secure checkout", API-created sessions, WooCommerce's redirect and popup modes, and LeadConnector payments.
The card form is built to be typed into safely: the card number masks its middle digits the moment the customer moves to the next field, the brand chip (Visa, Mastercard, Amex, Discover – and Credit or Debit) appears from the first digits, and expiry is picked from dropdowns, never typed. Mobile keychains can autofill the customer's own saved card. Sessions created with a Test key show a test-mode banner and never move money.

Payment methods on the hosted checkout
The hosted checkout adapts to how the customer pays:
- 1Card – the standard flow: masked number entry, brand chip, dropdown expiry, CVV, and ZIP, with the Pay button always showing the exact total. If your account runs a credit-card surcharge, the itemized Subtotal / Surcharge / Total box appears above Pay on credit cards.
- 2Gift card, partial – when your eGift program is on, "Have a Merchant360 gift card?" appears above the card fields. Applying a card shows exactly what it covers and what remains; the customer's card pays the remainder (and any surcharge computes on that card portion only).
- 3Gift card, full – a gift card covering the whole amount removes the card fields entirely and the button becomes Pay with gift card. If the card charge ever declines on a split payment, the gift redemption is automatically reversed – the balance never strands.

Refunding an order paid partly by gift card? Refund the card portion as normal, and void the gift redemption from your eGift tools so the stored value goes back on the card.
Developers: API keys & webhooks
The Developers page (in the Merchant360 menu, owner-only) is home base for building on Merchant360. It has two parts.
- 1API keys: mint a key with a name, a Test or Live mode, and the scopes it's allowed (presets cover Payments, Read-only, or Everything). The full key shows once, so save it. Minting a key asks for a texted security code; revoking doesn't – and you can tick several keys and revoke them together in one click. The same API charges cards and bank (ACH) alike, so your integration can take either.
- 2Webhooks: add your https endpoint and choose which events to receive (all events, or specific ones like invoice paid, payment succeeded or refunded, and ach settled or returned). Merchant360 signs every delivery with a secret you can rotate.
- 3Watch deliveries in the Recent deliveries log, with the status and attempt count, and Retry a failed one. Failed deliveries also retry on their own with backoff.

This is developer territory. If you work with an ISV or a web developer, point them here; if you don't build software, you can skip it.
