Payment links, widget & checkout

Payment links

A payment link is the fastest way to collect money without an invoice. You create a link, send it by email, text, or chat, and the customer pays on a secure hosted page on any device. Use it for a deposit, a quote the customer accepted by phone, a tip jar, or any one-off amount.

Each link is single-use: it locks after the first successful payment so it cannot be paid twice. Links can expire on a schedule (30 days by default), carry an invoice number and description for your records, and ask for any custom payment fields you enable.

A link is paid when its row shows Paid. The payment appears on Money → Transactions with the description and invoice number, the customer gets a receipt, and your payment alert goes out if Email me when a payment comes in is on. A bank payment on a link shows as paid once the debit is initiated and settles on the bank schedule.

If a customer says the link does not open, check the row: Expired links need a new link, Cancelled links were stopped on purpose, and a Paid link has already been used. If the customer's phone number is missing, Text is unavailable; add the number to the customer or paste the URL into your own message.

1. 1Go to Accept Payments → Payment Links and click New Payment Link.
2. 2Enter the Amount, or leave it at $0.00 to let the customer choose how much to pay. Add an Invoice #, an Expires in (days) value (blank never expires), a Description, and a Link name for your own records.
3. 3Add the Customer name, email, and phone so the link is tied to the customer and Text is available. Choose which Custom fields on this link to ask: All fields, Choose fields, or None.
4. 4Click Create Link. The green banner shows the URL: click Copy URL to paste it into an email or chat, or Text to send it straight to the customer's phone.
5. 5Watch the board. Each link shows Pending, Paid, Cancelled, or Expired. Click Cancel on a link you no longer want paid.

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, print as a QR code, or preview, and an embeddable form you paste into your own website so customers pay without leaving your site. Both use the same settings.

Go to Accept Payments → Pay Widget. The first time, click Turn on the Pay Widget; this needs card processing to be active. The widget starts with one-time fixed-amount payments, a $1 floor, and a $10,000 ceiling, all of which you can change.

You are done when the status pill reads Live and the Master switch is On. Copy URL gives you the public pay page address, and Preview shows exactly what a customer sees. Every payment through the page or the embed lands on Money → Transactions and in the widget's Recent activity list.

If customers report that payments are unavailable, the Master switch is Off. If a payment is refused for its amount, it is outside the Amount range. If your logo is missing on the page, upload it on the Business profile card in Settings.

1. 1Master switch: turn payments on or off. While off, visitors see a payments aren't available notice on both the hosted page and the embed.
2. 2Payment types: tick what the page accepts: Fixed amount, Donations, Save card on file, Pay external invoice, Pay Merchant360 invoice, or Subscriptions. Customers can only use types you tick here.
3. 3Amount range: set a Minimum and Maximum. These are enforced on the server, so nobody can tamper with the link to pay outside the range.
4. 4Branding: set your Brand color, an optional Logo URL, and the Success redirect and Cancel redirect pages customers land on. Your logo otherwise comes from your business profile.
5. 5Receipts: the From email is the address customers reach when they reply to a receipt, and the BCC email gets a copy of every receipt. Both are also on the Receipts card under Settings, which applies to every channel and takes priority when filled in.
6. 6Embed snippet: pick the Payment type, copy the snippet, and paste it into your website where the form should appear. It renders a secure payment frame, so no card data ever touches your site.
7. 7Pay Now button: build a ready-to-paste payment button for your website or email. The full walkthrough is in the Payment buttons section below.

Payment buttons

A payment button is a Buy Now, Pay Now, or Donate button for your own website or email. Customers click it and pay on your secure hosted page, or right on your page in a popup, and you never write a line of code.

Find the generator under Accept Payments → Pay Widget in the Pay Now button card. Everything you set is reflected in the live preview, and the HTML and plain link update as you go.

You are done when you have pasted the Button HTML into your website builder or email, or pointed an existing button at the Plain link. The button keeps working until you turn the widget off, and every payment through it appears in Recent activity and on Money → Transactions.

If the button opens a page that says payments are unavailable, the Master switch is Off. If a blank amount button refuses to open, turn on Donations under Payment types, since an open amount uses that type. If the popup does not appear on your site, the snippet was not pasted with the button; the button still links to the pay page as a fallback.

1. 1Label and amount: set the Button text (Pay Now, Donate, Book now, anything) and an Amount. With an amount set, the button charges exactly that. Leave it blank and the customer chooses what to pay, presented as a neutral Open payment or as a Donation.
2. 2Description: an optional line that rides along to the pay page and into your reporting, so you always know what the payment was for.
3. 3Style it: pick a Button color (or use your brand color), a Size (Small, Medium, Large), Corners (Pill, Rounded, Square), and Full width if the button should stretch. The preview shows exactly what you will paste.
4. 4Choose how it Opens: New page sends the customer to your hosted pay page (tick Open in a new tab if you prefer); Popup on your page opens the same secure form in an overlay on your own site.
5. 5Success URL (optional): after a successful payment, send the customer to your own thank-you page. In popup mode the overlay closes and redirects there; left blank, the customer sees the receipt with a Close button.
6. 6Copy it: Copy under Button HTML gives you the whole styled button to paste. Or copy the Plain link and point a button, image, or menu item you already have at it.

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 is a different way to collect. Mix and match them, or run just one; the page shows only what fits the link a customer opens.

Subscriptions need plans. On the Subscriptions page (linked from the widget) create each plan with a name, amount, billing period, and optional trial, setup fee, number of payments, and terms. Customers pick a plan on your pay page, the first payment is charged immediately, and the card is kept on file for the rest. The Subscribers list shows every enrollment with its status and next charge, and lets you pause, resume, retry a failed charge, or cancel.

The page also accepts what your Payment methods card allows: card, and bank when bank payments are enabled. Under dual pricing both prices are shown and the customer's choice sets the total.

If a customer cannot sign up for a plan, the Subscriptions payment type is off or the plan is archived. If a type the snippet asks for is not ticked under Payment types, the widget refuses it, so tick the type first.

1. 1Fixed amount: you set the price (through the embed's amount or the Pay Now button) and the customer pays it. Best for a product, a booking, or a set fee.
2. 2Donations: the giver picks the amount from preset chips or types a custom value. Best for nonprofits, tips, and pay-what-you-want.
3. 3Save card on file: no charge; the customer's card is vaulted for a future invoice or subscription.
4. 4Pay 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.
5. 5Pay 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.
6. 6Subscriptions: the customer enrolls in a plan you set up (daily to yearly) and the card is billed automatically.

API keys for developers

If you build your own website or app, the API key card on the Pay Widget page issues a key for server-to-server charges and for verifying payments. Issue a key, Re-issue to rotate it, or Revoke it. The full key is shown only once, so save it when it is created.

The embedded widget and hosted pay page do not need the key: they authenticate through the snippet itself. The key is only for direct calls from your server. Anyone with the key can run charges against your account, so treat it like a password.

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), 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 four, so you can confirm the order before you fulfil it.

You are done when the card shows the key prefix with its issued date. For scoped keys, webhooks, and Test versus Live keys, use the Developers page instead; it is the fuller developer console.

If a key leaks, click Re-issue: the old key stops working immediately and the new one is shown once. If Revoke is used by mistake, any integration using the key breaks until you issue a new one and update your server.

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, your code creates a secure checkout session through the Merchant360 API and sends the customer to a hosted pay page, or opens it as a popup with the Checkout Button. Card details never touch your site, and we redirect the customer back and notify your webhook when they pay.

The page gives you Get API keys, the API docs, and Try the demo, plus a list of every checkout session with its amount, description, customer, and status. Custom payment fields you enable for Checkout in Settings appear on the hosted page too.

A session is done when its status reads COMPLETE and view payment opens the transaction. Sessions created with a Test key carry a test badge and never move money.

If you just want a no-code way to collect a payment, use a payment link or the pay widget instead. If a session shows EXPIRED, the customer did not pay in time; create a new session. BANK PAYMENT PROCESSING means the customer chose Pay by bank and the debit is settling.

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 is the page behind the Payment Extension's Open secure checkout, API-created sessions, WooCommerce's redirect and popup modes, and LeadConnector payments.

Where Apple Pay is available, an Apple Pay button appears above the card form automatically. On an iPhone or Mac the customer confirms with Face ID or Touch ID; in other browsers they scan a quick code with their iPhone. Nothing to set up on your side, and your pricing rules (surcharge or dual pricing) show on the Apple Pay sheet. The same button appears on your e-invoices' pay page.

On the card form, 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. The Pay with Vault bar sits above the form for returning customers, and the Save my card with Vault box under it lets a new customer save their card for next time.

Sessions created with a Test key show a test-mode banner and never move money. Any custom payment fields enabled for Checkout are asked on the form, and the receipt is emailed the moment the payment succeeds.

If the Apple Pay button is missing, the customer's device or browser does not support it; the card form works as normal. If a customer's card is refused with an address error, the ZIP did not match the card's billing address.

Payment methods on the hosted checkout

The hosted checkout adapts to how the customer pays and to what your Payment methods card allows. Card is always there. Pay by bank appears when bank payments are enabled, and the session then shows BANK PAYMENT PROCESSING until the debit settles. Under dual pricing the customer sees the card price and the cash price and the total follows their choice.

The payment is done when the page shows the paid confirmation and the customer is sent to your success page. Card payments appear on Money → Transactions at once; bank payments appear on Money → ACH Transactions and settle on the bank schedule.

If Pay by bank is missing, switch on Bank (ACH / eCheck) on the Payment methods card. If the gift card box is missing, your eGift program is not on. If a split payment's card portion declines, the gift redemption is reversed automatically so the balance never strands.

1. 1Card: the standard flow with 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.
2. 2Pay by bank: the customer connects their bank or types the routing and account numbers, accepts the debit authorization on the page, and the payment shows the cash price under dual pricing. It settles in a few business days.
3. 3Gift 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 is computed on the card portion only.
4. 4Gift card, full: a gift card covering the whole amount removes the card fields entirely and the button becomes Pay with gift 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: scoped API keys and a signed-webhooks console with a delivery log. Only the account owner can create or revoke keys and endpoints.

API keys: each key has a name, a Test or Live mode, and the scopes it is allowed. Presets cover Payments, Read-only, or Everything, or tick scopes one by one. Test keys hit the sandbox and land on Test Mode Transactions; Live keys move real money. The full key is shown once at creation. The same API charges cards and bank (ACH) alike.

Webhooks: add your https endpoint and choose which events to receive: all events, or specific ones such as invoice paid, payment succeeded or refunded, and ach settled or returned. Every delivery carries an M360-Signature header your server verifies with the signing secret, which is shown once and can be rotated.

You are done when the key appears under Your keys with its scope count and last-used date, and the endpoint shows Enabled with deliveries in the Recent deliveries log. Send test event proves the wiring before real events arrive.

If a delivery shows a failed status, check the Code column (your server's HTTP response) and click Retry; failed deliveries also retry on their own with backoff. If a key was exposed, Revoke it and create a new one. If you cannot see the page, you are signed in as a team member; it is owner-only.

1. 1API keys: under Create an API key enter a Name, pick the Mode (Test or Live), choose a preset or tick Scopes, and click Create key. Copy the key from the Key created banner; it will not be shown again. Creating a key asks for a texted security code.
2. 2Revoke a key from Your keys, or tick several and click Revoke selected keys to revoke them together.
3. 3Webhooks: click Add endpoint, enter the Endpoint URL (https), choose All events or the specific events, and save. Store the Signing secret shown once.
4. 4Watch deliveries in Recent deliveries, with the status and attempt count, and Retry a failed one. Use Send test event to confirm your receiver, Rotate secret if the secret leaks, and Disable or Delete to stop deliveries.