Requires a plan that includes custom payment methods. Add one under Payment Methods.
Payment instructions
Write what the buyer should do in the rich text editor, such as your bank details, a wallet address or a payment handle. These variables are replaced per invoice:
Include
{unique_id} and ask the buyer to use it as the payment reference. Without a reference, matching an incoming bank transfer to an order is difficult.
Requiring proof of payment
Turn on Require Proof of Payment and the buyer must submit something before the order is put in front of you. Choose what they provide:- Text, for a transaction reference or transfer ID
- Image, for a screenshot of the confirmation
- Text or Image, for either or both
Approving a payment
An invoice on a custom method starts at Pending. When the buyer states they have paid, it moves to Confirming. That status is only a claim, and any buyer can trigger it without having paid, so treat it as a queue to verify rather than as evidence of payment.1
Confirm the money arrived
Check your bank, wallet or account, and match both the amount and the reference.
2
Open the invoice and process it
From Invoices. Processing delivers the items and sends the receipt exactly as an automatic payment would.
3
Decide whether to mark it as paid
Mark as paid sets the recorded paid amount to the invoice total. Use it when the money arrived outside SellAuth, which is the usual case. Leave it off if you are delivering without payment.
Redirect to your own payment page
Set a Redirect URL and the buyer is sent there instead of reading instructions. The same variables work, so your endpoint receives everything it needs:Processing an invoice from the API
One call completes the order:42 is the {id} value your redirect URL received. mark_as_paid=true records the invoice total as paid, since the money was collected outside SellAuth. A success response means the items were delivered and the buyer was emailed. Full parameters are in Process Invoice.
Create the API key under Account > Developers. Scope it to this shop and to the permissions it needs rather than granting full access, and keep it on a server or worker where it is never exposed to a browser. See Account Security.
Worked example: Stripe through a Cloudflare Worker
This Worker has two endpoints./start receives the buyer from your SellAuth checkout and opens a Stripe Checkout Session. /webhook receives Stripe’s confirmation and processes the SellAuth invoice.
Set your custom method’s redirect URL to https://your-worker.workers.dev/start?invoice={id}&ref={unique_id}&amount={price}¤cy={currency}&email={email}.
STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET, SELLAUTH_API_KEY and SELLAUTH_SHOP_ID as Worker secrets, and point a Stripe webhook endpoint at /webhook subscribed to checkout.session.completed.
Three details in this example matter, and any replacement should keep them:
- It verifies the webhook signature. Without that check, anyone who learns your Worker URL can deliver free orders to themselves.
- It carries the invoice ID in metadata rather than trusting a value posted back to it.
- It compares the amount paid against the amount owed before processing.
Next steps
Supported payment methods
Everything SellAuth integrates with directly.
How checkout works
Where a custom method invoice sits before you approve it.