How Delivery Works

Delivery type is set per product and decides two things: what the buyer receives when payment clears, and how stock is counted. It is picked when you create the product and can be changed later.

​

Which type to pick

The deciding question is where the thing being sold comes from. Use Serials when it already exists as a list of codes, Dynamic when a program produces it on demand, and Service when the product is text you write once, such as a method or a guide, or work a person does after the sale. Three things to know before you commit:

• Serials run out, Service does not. If every buyer must receive something different, such as their own key or account, that is Serials and your stock depletes. If every buyer receives the same thing, such as a method or a guide, that is Service and it sells indefinitely.
• Service only costs you time with manual fulfillment on. Left off, the text delivers itself and needs no attention at all.
• Dynamic is the only type that needs code. It is also the most capable. If nobody is going to build and host the endpoint, choose Service instead.

Delivery type can be changed later, so an early wrong guess is not permanent.

​

Serials

For anything that exists as a list of codes: license keys, accounts, gift cards, Nitro links, top up codes. You paste the items in, and each sale hands one to the buyer and removes it from stock. Covered in full in Serials and Keys.

​

Service

Service covers everything delivered by the text you write in the product’s instructions field, rather than from a stock list, a file or a webhook. It works two ways, and the Requires manual fulfillment checkbox decides which.

​

Selling text itself

Leave manual fulfillment off and the instructions are the product. The invoice completes the moment payment clears, and every buyer receives the same text immediately. This is how written products are sold: a method, a guide, a tutorial, a walkthrough, a list of settings, a link to something you host elsewhere. Nothing needs generating and nothing needs reserving, so stock is usually set to unlimited and the product sells without any involvement from you. Write the text in Instructions, or in a variant’s Override Instructions where tiers differ. Formatting and links are preserved, so a method with steps and screenshots links reads as you wrote it.

​

Work you do after the sale

Turn manual fulfillment on when the buyer is paying for work you carry out yourself: custom design, boosting, coaching, account work. The invoice stays paid but open until you close it, and the buyer can follow its progress. From the invoice page it moves through Mark as In Progress and then Mark as Completed. Both steps take a message to the customer, shown on their checkout page and included in the email. On In Progress the email is optional, with a checkbox for it. On Mark as Completed the customer is always emailed. Use it whenever the work takes time, so the buyer sees an accurate state instead of an invoice marked completed before anything has happened.

​

Dynamic

At the moment payment completes, SellAuth sends a POST request to a URL you control, and delivers whatever your server returns. Use it when the thing being sold is generated on demand, such as a key issued by your own licensing system. Your endpoint should return HTTP 200 with plain text, one deliverable per line. Requests carry an HMAC-SHA256 signature in the X-Signature header, and the secret for verifying it is under Miscellaneous in shop settings. Full request format, payload example and verification steps are in Dynamic Delivery. If a dynamic delivery fails, the invoice page has a Redo Delivery action on the affected item, which calls your endpoint again once it is fixed.

​

Dynamic or Service

Both cover work that happens after the sale. The difference is who does it. Dynamic suits anything a program can complete in seconds: minting a license, calling an API, running a bot that applies Discord boosts. The buyer is served immediately and you are not involved. Service suits anything needing a person, and anything where your automation is not built yet. It is also the safer starting point: sell with Service while you are still writing the endpoint, then switch the product to Dynamic once it works.

​

Files

Uploads attached to a variant, delivered as downloads after purchase. Suitable for e-books, templates, packs and assets. Files are managed under Downloadable Files and then attached per variant, so the same file can serve several products without uploading it again. How many files you can store, and the maximum size of each one, depend on your plan.

​

Physical

Nothing is delivered automatically. The buyer pays, you ship, and you record what happened on the order. Physical products need at least one shipping zone before they can be bought, and always collect a billing address. See Physical Products.

​

Instructions

Every product has an Instructions field, shown on the checkout page and in the delivery email once payment completes. What it should contain depends on the delivery type: Instructions can be overridden per variant, which is useful when a lifetime tier is redeemed differently from a monthly one.

​

Thank you message

Products also have a separate Thank You Message, shown on the checkout page next to the instructions once payment completes. It exists so the pleasantries stay out of the redemption steps: a buyer scanning for how to use what they bought should not have to read past a paragraph of thanks to find it. Unlike instructions it cannot be overridden per variant, since the same note usually suits every tier. If you want it identical across your catalogue, select your products in the product list and use Bulk Edit, Thank You Message. Where it appears relative to the other blocks is up to you. See checkout settings.

​

Extras that run on delivery

Discord auto join and auto role adds the buyer to a server and assigns roles when their payment clears, configured per variant. Redirect URL sends the buyer to a page of your choice after payment. If an invoice contains several items with redirect URLs, only the first is used.

​

When delivery goes wrong

Out of stock. The payment succeeded but stock ran out first. The buyer sees your out of stock message, and the invoice sits at Out of Stock until you restock and process it. Partially completed. Some line items delivered and others did not. Open the order and retry the failed item. Wrong item delivered. The invoice page can swap what was sent, either Replace from Stock or Replace Manually. See replacing a delivered item. The buyer says nothing arrived. Check the email address on the invoice first, since a typo there is the most common cause. The invoice page can resend the delivery email to a corrected address.

​

Next steps