# Welcome to PayNow PayNow is a merchant of record and storefront platform for game servers and online communities, and these guides cover opening a store through to getting paid. You build a catalogue. PayNow takes the payment, handles tax and fraud as the merchant of record, delivers the purchase to your server, and pays you out. ## Start here Three pages, in order, take a new store from empty to open.
1. Create your storeName, currency, platform, and the onboarding steps that end in going live./pages/8Q55Mj286GcSMSnLwG9X
2. Add your first productA product that actually delivers, with a command attached and tested./pages/5Ph0so7YzOYPPQEAj5jA
3. Check before you openThe things worth confirming before real customers arrive./pages/XpFFY85lKGQ2hoGdDUQR
Already selling on another platform? [Migrating from Another Platform](/getting-started/migrating-from-another-platform) imports your catalogue and explains what doesn't come across. ## Browse by section Sections follow your dashboard sidebar, so anything you can see in the dashboard is filed here alongside it.
ProductsPricing, subscriptions, delivery, tier groups, revoking./pages/5o1uogqyuXF6vLLEzJHZ
Orders & SubscriptionsEvery transaction, renewals, refunds, chargebacks and trials./pages/IyJoglYyUP4WkmzTm3CP
CustomersInventory, order history, manual customers and bans./pages/YLVc3yu3GwWxR59AOr3A
Commands & PlaceholdersHow a purchase reaches your server, and every placeholder you can use./pages/oYrWOiMVNjCH7GT2YMFG
Game Servers & DiscordLinking servers, Discord roles, webhooks and API keys./pages/rs28ioahe5vWCdGcW1nT
Your WebstoreTemplates, branding, tags, navlinks and the Twig reference./pages/dfsnBYTRnsh5vnwMPZKL
MarketingSales, coupons, gift cards, affiliates, upselling and follow-ups./pages/RCIKMk6WOKKjvJJVi5ZL
Payments & PayoutsGetting paid, what a sale nets, settlement and billing./pages/ZUjGT06Fev9ubL5JuFDy
AnalyticsRevenue, recurring performance and what the numbers mean./pages/vKHBsq5SnVnsgcBYAJZf
Store SettingsStore details, adaptive currency, team members, roles and permissions./pages/Crjz4MJQufJEiXGmOTTv
Your AccountYour profile, password, two-factor authentication and passkeys./pages/4wPt8cErwL1p7F21QDyo
ReferenceWhy a feature is missing, and what the terms mean./pages/CKjJ5v9aDKgetM0wj6XP
## Can't find a feature? A feature can be missing because your plan doesn't include it or your role doesn't allow it. [Why can't I see a feature?](/reference/feature-availability) covers both. ## Taking payouts without a store You don't need a store to receive affiliate settlements through PayNow. Choose **Setup Payouts** rather than **Create Store**, then see [Setting Up Your Payout Account](/getting-started/payout-account). ## Getting help [discord.gg/paynow](https://discord.gg/paynow) is fastest for most questions. Email for anything involving your account, payouts or verification. Either way, quote the order, subscription or payout ID (for example `#RH-1041`) if your question is about a specific one. These guides cover the dashboard. For the REST API, webhook payloads and SDKs, see [docs.paynow.gg](https://docs.paynow.gg). # Creating a Store Open a store, then work through the six onboarding steps to launch it. The **Stores** page lists every store you own or belong to. *Dashboard → Stores. Any account can create a store; no permission needed.* ## Before you start Verification stalls without three things: * Payout details: bank account information, or a PayPal address if your store is in USD. * Your Tax ID, or the equivalent local documentation. * A valid, unexpired government-issued photo ID: passport, driver's licence, national ID card or residence permit. You must be **18 or over** to verify. Under 18, a parent or guardian has to create the account and verify in their own name; contact to transfer it once you turn 18, rather than changing the name on a verified account. ## Create the store 1. Click **Create Store** in the top-right corner. 2. Enter a **Store Name**. 3. Enter a **Slug**. 4. Select your **Currency**. 5. Choose your **platform** and **integration type**. 6. Enter your **Support Email** and **Contact Email**. 7. Click **Create Store**.
The Stores page listing two stores, with the Create store button highlighted in the top-right corner.

An account with no stores yet goes straight to a Create a Store / Join a Store chooser instead of this list.

The Create Store form completed for a demo Minecraft store called Ravenhold.
### Store fields | Field | What it does | Can you change it later? | | -------------------- | -------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Store Name** | Shown to customers throughout checkout and on receipts. | Yes | | **Slug** | Short identifier used in your store URL. | Technically yes, but every link you've shared will break. Treat it as permanent. | | **Currency** | What prices are set and charged in. | No. See below. | | **Platform** | The game or service you sell for. Customises which store features you get. | Yes, from Store Settings. Switching to or from a third-party integration opens a **Platform Change** warning: it affects your platform fees and available functionality. | | **Integration type** | Hosted Webstore, Headless API, or Third-Party Integration. | Yes, but it changes which parts of the dashboard apply to you. | | **Support Email** | Shown to customers. Where they contact you. | Yes | | **Contact Email** | Where PayNow contacts you. Not customer-visible. | Yes | {% hint style="warning" %} **Currency is effectively permanent.** It sets what customers are charged in and what your payouts settle in. A global audience doesn't need multiple stores: [Adaptive Currency](/store-settings/adaptive-currency) presents local prices on top of your base currency. {% endhint %} ### Choosing an integration type | Type | Use when | You manage | | --------------------------- | ---------------------------------------------------------------- | --------------------------------------------------------- | | **Hosted Webstore** | You want PayNow to host and render your storefront. Most stores. | Products, appearance and promotions, all in the dashboard | | **Headless API** | You have your own site and want to drive checkout yourself. | Your own frontend; PayNow handles payment and delivery | | **Third-Party Integration** | Another platform creates and drives your store. | Very little. | ## The six onboarding steps The **Onboarding** section walks you through launch. You can leave and come back; progress is saved.
The six-tile onboarding banner on the dashboard, with four launch steps marked complete and two still outstanding.
### Step 1: Create a product [Your First Product](/getting-started/your-first-product) is the quick walkthrough; [Creating a Product](/products/creating-a-product) is the full field reference. ### Step 2: Link a game server Connects your store to the server that delivers purchases. Without it, payments succeed and customers receive nothing. See [Game Servers](/integrations-and-commands/game-servers). ### Step 3: Set up payouts 1. Click **Setup Payouts** on the Payouts page. 2. Work through the wizard: your address (email, phone, postal), your payment method (PayPal, local bank transfer, or wire), your tax forms, then review and confirm. **Tipalti**, our payments partner, handles payout onboarding, so this step opens their form. [Tax Forms](/getting-started/tax-forms) covers which form applies to you; US recipients, individuals as well as companies, receive a 1099-K at year end. The rest is in [Setting Up Your Payout Account](/getting-started/payout-account). **PayPal payouts are only supported for USD stores.** On any other store currency, use local bank transfer or wire. ### Step 4: Verify your identity Upload your government-issued ID and any additional requested details. PayNow uses Stripe to run the check, which covers document verification, biometric verification and information validation. It is required to meet anti-money laundering (AML) and know-your-customer (KYC) regulations, payment processing partner standards, and Visa/Mastercard compliance requirements. It usually completes quickly. This step only becomes available once payout onboarding is complete. ### Step 5: Store review PayNow reviews the store before it can sell. When every other requirement is met, the step becomes **Escalate to review** and you submit the store yourself; review can take up to several business days. ### Step 6: Enable live mode Once approved, use the **Enable Live Mode** button on the Onboarding page. Work through the [Going Live Checklist](/getting-started/going-live-checklist) first. # Your First Product A ten-minute walkthrough that takes you from an empty catalogue to a tested, purchasable product. This is the short path: one simple product, a command so it actually delivers, and a test purchase to prove it. For every field explained, see [Creating a Product](/products/creating-a-product). *Dashboard → Content → Products. Needs `product_read` to view, `product_create` to add.* You need a [linked game server](/integrations-and-commands/game-servers) first. Without one there's nothing to deliver to, and no way to test properly. ## 1. Create the product 1. Go to **Content → Products**. 2. Click **Create**. 3. Fill in the essentials: * **Name**: what the customer sees. `Starter Kit` * **Price**: `2.99` * **Description**: what they get. Be concrete. Customers refund things they didn't understand. 4. Under **Lifetime → Product lifetime cycle**, leave **Allow One Time Purchases** ticked and **Allow Subscriptions** unticked. Those are the defaults. Subscriptions add renewal behaviour you don't want to debug on your first product. 5. Click **Create**.
The product creation form filled in for a Starter Kit priced at 2.99 with Allow One Time Purchases ticked.
## 2. Attach a command Skip this step and the customer pays and receives nothing. 1. Open the product you just created. 2. Open **Deliverable Actions → Commands**. 3. Set the stage to **On Purchase**. 4. Type the command your server console would run, with a placeholder where the player's name goes. On Minecraft that looks like: ``` give {customer.minecraft.name} diamond_pickaxe 1 ``` On a Steam game such as Rust, use `{customer.steam.id}` instead. 5. Save. {% hint style="warning" %} **Use the placeholder, not your own username.** A command with your name hard-coded in it gives *you* the item every time someone else pays. {% endhint %} The command editor has an **Available variables** link listing every placeholder, each one click-to-copy. [Commands & Placeholders](/integrations-and-commands/commands) explains them. ## 3. Make it purchasable A product can exist and still not appear on your storefront. Under **Lifetime → Product availability period**, confirm **Disable product** is unticked and that **Enabled from** / **Enabled until** don't exclude today. Then check your storefront in a **private browsing window**. Your logged-in dashboard session can show you things customers cannot see. ## 4. Test it before anyone else does There is no sandbox or test mode, so the test is a real order. You don't have to pay for it. Any of these gets you through checkout for nothing: * A **100%** [**coupon**](/marketing/coupons) you make for yourself and delete afterwards. * A [**gift card**](/marketing/gift-cards) you issue to yourself. * A **free product**, priced at 0, that you hide once you're done. Buying it properly and refunding yourself works too, but it puts a refund on your records for no reason. Then: 1. Buy the product using one of the above. 2. Watch the server console. The command should run within seconds. 3. Check **Content →** [**Orders**](/orders-and-subscriptions/orders). The order should be listed. 4. Check the receipt email arrived. All four true means a working product. Repeat for the rest of your catalogue, using [Tags](/your-webstore/tags) to organise it and [Tier Groups](/products/tier-groups) for ranks that upgrade between each other. Then work through the [Going Live Checklist](/getting-started/going-live-checklist). # Migrating from Another Platform Import your products and categories from Tebex, and understand exactly what does and does not come across. The data migration tool imports your catalogue from another platform so you don't rebuild it by hand. *The **Data Migrations** page is not in the main sidebar. Reach it from your account menu → **Migrate Data** (shown only if you have `product_create` and `tag_create`), or from the **Moving from a competitor?** card on the Onboarding page.* ## What gets migrated The gaps catch people out, so read this before you start. | | Migrated? | | ------------------------ | -------------------------------------------------------------------- | | **Products** | ✅ Yes, **except their commands** | | **Categories** | ✅ Yes | | **Templates** | ⚠️ Supported, but separately. Create them under the **Webstore** tab | | **Commands** | ❌ No | | **Customers** | ❌ No | | **Active subscriptions** | ❌ No | | **Order history** | ❌ No | {% hint style="danger" %} **Commands do not migrate.** Products arrive with their names, prices and descriptions intact, and deliver **nothing** until you add commands to each one. The store goes live, customers pay, and nothing happens in game. Budget time to re-add commands to every product before you go live, and test at least one purchase per product type. See [Creating a Product](/products/creating-a-product). {% endhint %} ## Existing subscribers do not carry over Recurring billing agreements live with the old platform's payment processor and can't be transferred. A subscription bought on Tebex stays on Tebex. Those subscriptions carry on billing on the old platform until they lapse, and they pay out there too. Nothing about the migration cancels them or moves them. An old subscriber lands on PayNow when they next buy something. What you do with the old store after that is up to you. ## Running a migration ### 1. Collect your Tebex tokens You need two, both from your Tebex account. The form links to both. | Token | What it is | | ---------------------- | --------------------------- | | **Headless API Token** | Your Tebex **public** token | | **Plugin Token** | Your Tebex **plugin** token | The Plugin Token is a secret. Paste it directly into the migration form. Don't post it in Discord, a support ticket, or anywhere else while asking for help. ### 2. Start the migration 1. Open the **Data Migrations** page (account menu → **Migrate Data**). 2. Click **New data migration**. 3. Set **Import data from** to **Tebex**. 4. Paste your **Headless API Token**. 5. Paste your **Plugin Token**. 6. Click **Start**.
The Create a data migration dialog with Tebex selected as the source, showing which data will be migrated.

The dialog states exactly what will be imported before you start.

### 3. Re-add commands Work through every imported product and attach its commands. See [Creating a Product](/products/creating-a-product) and [Global Commands](/integrations-and-commands/global-commands). ### 4. Migrate your templates [Templates](/your-webstore/templates) go through the Webstore tab rather than the migration tool. PayNow templates have a **Tebex compatibility mode**, so an existing Tebex template can be uploaded and run with minimal rework. ### 5. Test before announcing Run through the [Going Live Checklist](/getting-started/going-live-checklist) and buy at least one product yourself to confirm delivery works. ## Suggested order 1. Run the data migration. Products and categories arrive. 2. Re-add commands to every product. 3. Upload or rebuild your template. 4. Link your [game server](/integrations-and-commands/game-servers). 5. Test purchases for each product type. 6. Set up [payouts](/getting-started/payout-account) and complete verification. 7. Go live. # Setting Up Your Payout Account Set up how PayNow pays you, including the payouts-only path for affiliates who do not run a store. Before PayNow can send you money, complete payout onboarding. **Tipalti**, our payments partner, handles it, so parts of this flow open their forms rather than the PayNow dashboard. *Dashboard →* [*Billing*](/payments-and-payouts/billing) *→* [*Payouts*](/payments-and-payouts/payouts)*. Owner-only: the page isn't permission-gated and no role grants it. See* [*Account Payouts vs Store Payouts*](/payments-and-payouts/account-vs-store-payouts)*.* ## Two ways to use PayNow payouts | You want to… | Path | | ---------------------------------- | ----------------------------------------------------------------------- | | Sell things through a store | Create a store, then complete payout onboarding as part of launch | | Receive affiliate settlements only | Register, choose **Setup Payouts** at first login, never create a store | You do **not** need a store to receive settlements through PayNow, and you can [create one](/getting-started/creating-a-store) from the dashboard later if you change your mind. ## Payouts-only setup (affiliates) ### 1. Register 1. Go to [dashboard.paynow.gg/auth/register](https://dashboard.paynow.gg/auth/register). 2. Click **Register Now**. 3. When asked **"What do you plan to sell?"**, choose the closest match. 4. Click **Continue** and finish sign-up. ### 2. Choose the payouts path at first login On first login you're asked how to proceed. Choose **Setup Payouts**, not *Create a Store* and not *Join a Store*, then click **Continue**. You can create a store later from the dashboard if you change your mind. ### 3. Complete Tipalti onboarding 1. Go to **Payouts** in the sidebar. 2. Click **Setup Payouts** in the top-right. 3. A **Payout Setup** dialog opens with Tipalti's form embedded in it. Provide your personal or business details (name, address, contact information), your payout method (local bank transfer, wire, and others depending on country, plus PayPal if your store is in USD), and your tax information. 4. Click **Next** through each section. 5. Submit. Your payout method is then reviewed. The tax step is a Tipalti-hosted form inside an iframe, and it's where people get stuck. [Tax Forms](/getting-started/tax-forms) covers which form applies to you and how to complete it. Once approved, you can withdraw.
The Payouts page before onboarding, showing the eligibility warning and Setup Payouts button.
### 4. Receive payments 1. Share your **PayNow Payout ID** with the platform paying you. 2. Confirm your payout settings on their side. 3. Settlements appear in your PayNow balance. Which platforms support PayNow as a payout destination depends on the affiliate network or service, so ask them. ## Choosing a payout method Which methods you're offered depends on your country. **PayPal is USD stores only** and isn't offered on any other store currency. You can change method later from the Payouts page; the new one goes through review again. Cost is the thing worth comparing, because the gap between methods is large. ### What the method costs you Tipalti sets these fees and deducts them from the payment. | Payment method | Transaction fee | | ---------------------------------------------------- | ---------------------------------------------------------- | | **ACH** | USD 1.12 | | **eCheck (Local)** | USD 1.12 | | **Check** | USD 2.24 | | **eCheck** | USD 6.74 | | **PayPal** (US resident) | USD 1.12 + 2.00%, capped at USD 2.25. **USD stores only** | | **PayPal** (non-US resident) | USD 1.12 + 2.00%, capped at USD 23.59. **USD stores only** | | **Wire transfer** (US resident) | USD 16.85 | | **Wire transfer** (non-US resident, paid in non-USD) | USD 22.47 | | **Wire transfer** (non-US resident, paid in USD) | USD 29.21 | **A wire costs roughly fifteen times an ACH for moving the same money.** Take the local option where your country has one. Because the fee is a flat charge per payment rather than a percentage, **how often you withdraw costs you more than which method you use**. Four weekly withdrawals pay the fee four times; one monthly withdrawal pays it once. ### FX fees Charged on top when the payment currency differs from the currency you chose to be paid in. **These vary by country**; the defaults are: | Payment amount | FX fee | | --------------------------- | ------ | | Up to USD 499.99 | 3.00% | | USD 500.00 to USD 99,999.99 | 2.50% | | Over USD 100,000.00 | 1.90% | {% hint style="warning" %} **Don't use payouts as a currency exchange.** On a $400 payout the FX fee alone is $12, more than ten times the ACH charge. Take the payout in your local currency where that option exists. PayNow earns nothing from payout fees or FX; we flag this so you keep more of your money. {% endhint %} ## Tax documents Requirements depend on where you are. US recipients receive a **1099-K** at year end, whether you sell as an individual or through a company. Make sure everything you supply about yourself or your business is accurate; withdrawals stay unavailable until payout setup is fully complete. # Tax Forms The tax form step in payout onboarding, why it exists, and the practical reasons submissions get rejected. Payout setup asks for your tax information, and withdrawals stay unavailable until payout setup is complete. *Dashboard → Billing → Payouts → **Setup Payouts**. The full onboarding flow is in* [*Setting Up Your Payout Account*](/getting-started/payout-account)*.* {% hint style="warning" %} **PayNow can't advise you on tax.** We're not licensed to, and a wrong answer from us could cost you money or leave you filing incorrectly. Which form applies to you, how to complete it, and what your tax position is are all questions for a qualified accountant in your country. That includes the ones that sound simple, like whether you count as a US person or which classification your company falls under. {% endhint %} ## The form isn't ours **Setup Payouts** opens a form hosted by **Tipalti**, PayNow's payout provider, embedded in the dialog. It looks and behaves like their product because it is: use the buttons inside the panel rather than your browser's back button, and expect their wording on any errors. If the panel loads blank, an ad blocker or strict tracking protection is usually blocking the embed. Try a private window with extensions off before contacting support. ## Let the questionnaire pick the form Tipalti's **tax questionnaire**, inside the form step, works out which form you need from the answers you give. Use it rather than picking a form yourself. It does not save your answers. Close it, navigate away, or let it time out before finishing and you start over from the first question. Set aside a few uninterrupted minutes, with your entity type and tax ID to hand. If you're shown a form you weren't expecting, the **country or entity details on an earlier step are probably wrong**. Go back and correct those rather than completing a form you don't think applies to you. ## The forms you might see PayNow uses the standard set. The questionnaire picks whichever fits your answers. | Form | Who it's for | What it does | | ------------ | ----------------------------------------------- | -------------------------------------------------------------- | | **W-9** | US persons, whether an individual or a business | Provides your taxpayer details to the US authorities | | **W-8BEN** | Individuals outside the US | Certifies you are not a US taxpayer | | **W-8BEN-E** | Businesses outside the US | The entity version of the W-8BEN, and the longest of the three | Which of those is yours depends on your tax residency and how you're set up, which is exactly the part we can't answer for you. ## Why submissions get rejected These are the mechanical causes, not tax questions. They account for most rejections. | Cause | What happens | | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | | **Name and TIN don't match** what the tax authority holds | Validation fails. The details have to match their records exactly. | | **Special characters in your legal name** | Tipalti strips them to the characters permitted, so adding punctuation to work around a rejection won't help. | | **A newly issued EIN** | Allow 2 to 3 weeks from issue before it can be validated. | | **An address that contradicts the form** | For example a US address on a form certifying you are not a US taxpayer. | If a rejection isn't explained by one of those, it's a question for your accountant rather than for support. ## After you submit Tipalti validates the form. Simple validation is quick; TIN matching can take longer. Your **payout onboarding status** updates on the [Payouts](/payments-and-payouts/payouts) page. Until it clears, sales still accumulate and are **not lost**, but you cannot withdraw. If it's rejected, Tipalti states a reason. Correct it and resubmit by reopening **Setup Payouts**. Start this before you need the money. ## At year end US recipients receive a **1099-K** covering the payouts made to their payout account, whether you sell as an individual or through a company. It follows the **account**, not the store, so an account receiving payouts from several stores gets one combined form. See [Account Payouts vs Store Payouts](/payments-and-payouts/account-vs-store-payouts). ## Getting help Anything about your tax position goes to an accountant. If the form won't submit or the panel won't load, that part is ours: email with your store slug, the step you're on, and the exact error text. {% hint style="danger" %} Never share your SSN, ITIN or EIN in Discord, in a screenshot, or in a support ticket. PayNow will never ask for it. It goes into the Tipalti form and nowhere else. {% endhint %} # Store Review What PayNow's compliance team checks before a store can go live, and what is not allowed. Every store is reviewed by PayNow's compliance team before it can take real payments. Review confirms that PayNow can support what you are selling and the game or platform you are selling it for. *Dashboard → Onboarding → **Escalate to review**. Store owner only.* ## What to have ready before you submit Compliance reviews a working store, not an empty one. Have all three in place: | | | | ------------------------------ | ------------------------------------------------------------------- | | **A store others can look at** | Your storefront reachable, with branding and your products visible. | | **Your products set up** | Real products with real names, prices and delivery configured. | | **A store description** | What you sell, and for which game or platform. | Reviewers use these to check that the game and the items are ones PayNow can support. If your game is not one of the options PayNow lists, say so in the description. It does not mean no, but it adds a step while compliance looks at the game itself. ## Required links in your storefront Your storefront footer must link PayNow's **Terms**, **Privacy Policy** and **Buyer Agreement**. Add them to your template footer before submitting. A store missing them will come back from review. See [Editing Template Files](/your-webstore/editing-template-files). ## What PayNow does not accept {% hint style="warning" %} **Everything you sell must deliver instantly and automatically.** PayNow does not support services, manual fulfilment, or anything a human has to action after payment. Instant delivery is what makes chargeback protection possible, so this is a condition of the platform rather than a limitation of the dashboard. {% endhint %} Also refused: * **Donations.** The buyer has to receive something for their payment. A product that gives nothing back is not allowed, whatever it is called. * **Payment facilitation.** You cannot use PayNow to take payments on behalf of other sellers. * **Some games and platforms.** Compliance maintains this list, and it changes. If you are unsure, ask before you build the store. ## Naming virtual currency If you sell an in-game currency, name the product for what the buyer receives rather than after a real currency. "500 Tokens" passes review where "500 Dollars" does not. Describe the actual item being sold. A product whose name and description only reference a currency amount will be sent back. ## Testing before you go live You do not need live payments to check that delivery works. Any of these will run your commands without taking money: * a **coupon** or **gift card** that brings the total to zero * a product priced at **0** * assigning the product directly to a customer from their [inventory](/customers/managing-customers#inventory) ## If you are under 18 You must be 18 or over, or the age of majority where you live, to be verified as a store owner. Below that, a parent or legal guardian completes onboarding in their own name, and the payout bank account must be in that same person's name. The store can be transferred to you once you reach the age of majority. ## How long it takes Compliance works through submissions in the order they arrive. There is no way to expedite a review, and asking does not move a store up the queue. Use the waiting time to test delivery with a zero-cost order. # Going Live Checklist Everything that must be true before you switch your store into live mode. Live mode lets real customers pay you real money. Confirm all nine items first. *Dashboard → Onboarding.* ## Before you flip the switch ### 1. Your store details are correct Name, slug and currency are all customer-visible. The **slug** appears in your store URL, and changing it later breaks every link you've shared: social posts, Discord pins, in-game messages. ### 2. At least one product exists and is visible A product can exist but not be purchasable: check that **Disable product** is off and that the **Enabled from** / **Enabled until** dates don't exclude today. Open your storefront in a private browsing window and confirm you can see and click what you expect to sell. See [Products](/products/products). ### 3. Delivery is wired up and tested Payment succeeds, nothing arrives in game, customer opens a dispute. Confirm all three: * A game server is linked and showing as connected. See [Game Servers](/integrations-and-commands/game-servers). * Every product has commands attached. See [Creating a Product](/products/creating-a-product). * You've bought one product yourself, straight after going live, and watched the command execute. There is no sandbox, so this is a real payment. Refund it afterwards if you want. {% hint style="warning" %} Don't skip that purchase. Reading the command back doesn't prove it runs, and otherwise the first person to find out will be a paying customer. {% endhint %} ### 4. Payouts are set up and approved Nothing else on this list matters until this one is done: a store cannot go live without it. Approval isn't instant, so start it first rather than last. See [Setting Up Your Payout Account](/getting-started/payout-account). ### 5. Identity verification is complete Required before your store can be approved. You must be 18 or over, with a valid unexpired government-issued ID. See [Creating a Store](/getting-started/creating-a-store#step-4-verify-your-identity). ### 6. Support and contact emails are monitored Customers email the support address on your store. ### 7. Branding is applied See [Branding](/your-webstore/branding). ### 8. Your team has the right roles Give staff the narrowest role that lets them do their job. Don't hand refund or product-edit rights to moderators who only need to look things up. See [Roles](/store-settings/roles) and [Permissions Reference](/store-settings/permissions). ### 9. Your store has passed review PayNow reviews stores before they can go live. Once every other requirement is met, use **Escalate to review** on the Onboarding page to submit the store. Compliance checks what you sell and the game you sell it for, and there are things it will not approve. Read [Store Review](/getting-started/store-review) before you submit. ## Going live Live mode is enabled from the Onboarding page. There is no live-mode control in Store Settings. 1. Open **Onboarding**. Once the store is approved, the Onboarding Status card shows an **Enable Live Mode** button. 2. Click it. The **Enable Live Mode** dialog asks you to review and confirm your understanding of PayNow's platform policies, with three checkboxes: prohibited items, fraud, and agreement to the Creator Agreement, Terms of Use and Privacy Policy. 3. Tick all three. The **Go Live** button stays disabled until you do. 4. Click **Go Live**.
The Enable Live Mode confirmation with three policy checkboxes and a disabled Go Live button.
## In the first hour 1. Buy something yourself using a 100% [coupon](/marketing/coupons), a [gift card](/marketing/gift-cards) or a free product. Confirm checkout completes, the command runs, and the receipt email arrives. 2. Check [Orders](/orders-and-subscriptions/orders) to confirm the order recorded correctly. 3. Check the [Dashboard](/analytics/dashboard) to confirm revenue is being counted. 4. Watch [Abandoned Checkouts](/marketing/abandoned-checkouts) for the first day. # Products The Products list, how the catalogue is organised, and where to go for each task. Your catalogue is what customers buy. Promotions, upsells and tiers sit on top of it. *Dashboard → Content → Products. Needs `product_read` to view, `product_create` to add.*
The Products list showing seven products with their prices, tags, stock and last-updated details.
## Product types The type you choose changes how the product is billed and what happens after purchase. | Type | Billed | Use for | Notes | | ---------------- | --------- | ----------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | **One-time** | Once | Currency packs, kits, cosmetics, single unlocks | Simplest. Start here. | | **Subscription** | Recurring | Ranks, memberships, monthly perks | Generates [Subscriptions](/orders-and-subscriptions/subscriptions); can be grouped into [Tier Groups](/products/tier-groups) | ## What you can do from here | Task | Guide | | ------------------------------------------ | ------------------------------------------------------------ | | Create a product from scratch | [Creating a Product](/products/creating-a-product) | | Copy an existing product | [Duplicating a Product](/products/duplicating-a-product) | | Apply changes across many products at once | [Bulk Assigning Products](/products/bulk-assigning-products) | | Build upgradeable rank ladders | [Tier Groups](/products/tier-groups) | | Group products on the storefront | [Tags](/your-webstore/tags) | | Discount a product | [Sales](/marketing/sales) | | Offer an add-on at checkout | [Upselling](/marketing/upselling) | | Offer a free period first | [Trials](/orders-and-subscriptions/trials) | ## Organising a growing catalogue Past roughly a dozen products, the storefront becomes the constraint. Three tools do three different jobs, which is a common point of confusion: | Tool | What it controls | | ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Tags](/your-webstore/tags) | How products are grouped and displayed on the storefront. Purely presentational. | | [Tier Groups](/products/tier-groups) | How subscription products relate to each other, so a customer can upgrade from Iron to Gold and be charged the difference rather than starting over. Behavioural. | | [Navlinks](/your-webstore/navlinks) | How customers move around the storefront. Navigation, not grouping. | ## Visibility A product can exist without being purchasable. Use that to prepare a launch before announcing it, to retire a product without deleting its order history, or to sell something only through a direct link. ## Deleting versus hiding Prefer hiding. Deleting a product that has been sold complicates order history and any active subscriptions attached to it. Hidden products stop being purchasable immediately, and records stay intact. # Creating a Product The complete field reference for building a product, covering details, delivery, lifetime, stock, upsells and metadata. This is the full reference. For one working product quickly, start with [Your First Product](/getting-started/your-first-product) and come back here for the detail. *Dashboard → Content → Products → **Create Product**. Needs `product_create`.*
The Create a Product page showing the Details section with name, slug, description and price.
## Details | Field | What it does | | --------------- | ----------------------------------------------------------------------------------- | | **Name** | Customer-facing product name. | | **URL slug** | Appears in the product's storefront address. Changing it later breaks shared links. | | **Description** | What the customer receives. | | **Price** | The amount charged, in your store currency. | List every feature the buyer receives, concretely. "VIP rank" tells them nothing; "VIP rank: `/fly` in spawn, 3 home points, coloured chat name, priority queue" tells them what they're paying for, and gives you something to point at if they later claim they were misled. ## Regional Pricing Charge different amounts in different regions rather than converting one price everywhere. A **Business** plan feature, and it appears only when you **edit** a saved product: a globe button beside the **Price** field. Per region you set **Price**, **Currency**, whether the price is **Tax Inclusive**, and an **Enabled** toggle. **Base Price Percentage** covers every region you haven't given an explicit override, as a percentage of your base price. PayNow's own note in that dialog: regional pricing is for advanced users, and there is **no proxy or VPN prevention** behind it. Anyone can present themselves as being in your cheapest region. Price the gap accordingly. This is separate from [Adaptive Currency](/store-settings/adaptive-currency), which converts one price into local currency at PayNow's expense. Regional pricing sets genuinely different prices. ## Tags Tags organise and categorise products on your storefront. See [Tags](/your-webstore/tags). ## Game Servers **Select the server(s) this product applies to.** This is how PayNow knows where to deliver the purchase. {% hint style="danger" %} Miss this and the product sells but delivers nowhere. If you run several servers from one store, selecting the wrong one is just as bad: the customer pays and the perk lands somewhere they aren't playing. See [Game Servers](/integrations-and-commands/game-servers). {% endhint %} ## Custom Variables Select [custom variables](/integrations-and-commands/custom-variables) from the dropdown to collect input from the customer at checkout, such as a colour, a name tag or a quantity. The values feed into command execution, so delivery can be personalised rather than fixed. ## Required Products Gate this product behind other purchases: the customer must already own the listed products before buying this one. Useful for add-ons, expansions, and anything that only makes sense on top of a base package. | **Require all products** | Behaviour | | ------------------------ | -------------------------------------------------------- | | **Off** (default) | The customer needs **any one** of the selected products. | | **On** | The customer needs **all** of them. | ## Tier Group Assign the product to a [tier group](/products/tier-groups) for cumulative pricing and automatic subscription upgrades and downgrades. Customers who own a lower tier pay only the difference. ## Lifetime Two cards that are easy to confuse. **Lifetime cycle** is how long access lasts *after* a purchase. **Availability period** is when the product can be *bought at all*. ### Product lifetime cycle | Field | What it does | | ---------------------------- | --------------------------------------------------------------------------------- | | **Allow One Time Purchases** | Customers can buy it outright. | | **Allow Subscriptions** | Customers can subscribe to it. | | **Should Expire** | Access ends after a set duration. Most servers use one month. | | **Expires / Renews in** | The length of that duration. For subscriptions this is also the renewal interval. | You can enable both purchase types on one product. ### Product availability period | Field | What it does | | ------------------- | ----------------------------------------------------------- | | **Disable product** | Turns it off immediately by setting *Enabled until* to now. | | **Enabled from** | When it becomes purchasable. Empty = available now. | | **Enabled until** | When it stops being purchasable. Empty = no end date. | Use this for scheduled launches, limited drops, and retiring a product without losing its order history. ### Trial configuration Trials work on **subscription products only**. **Allow Subscriptions** must be enabled for any trial setting to take effect. In PayNow's production testing, trials converted roughly **1 in 4** users into paying subscribers. | Field | What it does | | ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | | **Allow Trials** | Enables trials for this product. | | **Revoke immediately when canceled** | Removes access on cancellation instead of at the trial's scheduled end. | | **Trial Period** | How long the trial lasts. At the end the customer is charged automatically unless they cancelled. | | **New Customers Only** | Only customers with no prior orders in a configurable window can start a trial. | | **Customer must have no orders in the last** | That window. | | **Allow Repeat Trials** | Lets previous trialists or owners trial again after a cooldown. | | **Customer must not have ordered the product in the last** | That cooldown. | Trials have their own command triggers: **On Trial Started** and **On Trial Expired** in the Commands section. The old docs call the second one "On Trial Ended"; the dashboard says **On Trial Expired**. **On Purchase fires only when a trial converts to paid**, so a product relying solely on On Purchase delivers nothing during the trial itself. Dedicated webhooks exist for trial started and trial ended events. A custom storefront needs its template updated to support the trial flow. Full detail: [Trials](/orders-and-subscriptions/trials). ## Stock Limit how many can be sold, for balance (too many of one package can distort a server) or for scarcity (limited availability drives urgency, and restocks are an event worth announcing). ## Upselling Configure upsells specific to this product. When it's added to the cart, your recommendations are offered at checkout. Tick **Enable Upselling**, then **Add Recommendation**. The fields match store-wide upsells plus one that only exists here: **Min. Product Qty**, the minimum quantity of *this* product required in the cart before the upsell shows. **Per-product upsells take priority over store-wide upsells** where both apply. See [Upselling](/marketing/upselling). ## Deliverable Actions ### Commands How the purchase reaches the player. Commands run on the game server(s) you selected, using placeholders that PayNow swaps for the buyer's real details. ``` lp user {customer.minecraft.uuid} parent add vip ``` Each command has a **stage** deciding when it fires, an **Execute when online** option, and an optional server override. There are 33 placeholders, and the two customer sets are not interchangeable: `{customer.*}` is who the product is *for*, `{order.customer.*}` is who *paid*. On a gift those differ. [Commands & Placeholders](/integrations-and-commands/commands) covers all of it, with the full placeholder reference and worked examples per game. ### Gift card Issue a [gift card](/marketing/gift-cards) equal to the product's price on purchase. ### Discord Trigger [Discord](/integrations-and-commands/discord-servers) actions on purchase: assign roles, kick or ban a user, or generate an invite link. Requires a Game Server entry configured for the Discord bot, set up much like a normal game server. ### Downloadable files Attach a file the customer receives immediately. The download link appears on the checkout screen and is emailed to them for later access. {% hint style="warning" %} **Updating the file gives every previous buyer the new version automatically.** To sell an expansion rather than give it away to everyone who bought the original, **create a new product**. Only update the file in place when you're fixing or improving the thing they already bought. {% endhint %} ## Metadata Click **Add field** and enter a key and value. Customers never see metadata; it appears in **webhook payloads** and the **Product API** response. Use it to send structured data to external systems, tag products for backend automation, or store configuration read by delivery scripts. ## Product image Add the image after creating the product: open it again and use the control in the top right of the edit page. Recommended size is at least **256×256px**. Customers process the image before they read your description. # Duplicating a Product Copy an existing product to build variants quickly without rebuilding every field. Duplicating copies every setting from an existing product into a new one and opens it for editing. It's the fastest way to build a range of related products, and every field it copies is explained in [Creating a Product](/products/creating-a-product). *Dashboard → Content → Products → the **actions** column on the right. Needs `product_create`.* ## Duplicating 1. Go to **Content → Products**. 2. Find the product in the list. 3. In the **actions** column on the right, click **Duplicate**. The new product opens straight away, carrying everything from the original.
The Products list with the Duplicate button on the Gold Rank row highlighted and its tooltip showing.

Duplicate is a single button in the Actions column, not an expanding menu — one click makes the copy.

## When it saves time Rank ladders: build Iron Rank fully, duplicate twice for Gold and Obsidian, adjust name, price and commands, then put all three in a [tier group](/products/tier-groups). Per-server variants: duplicate and change the game server selection. Seasonal versions: duplicate last year's event package and adjust the availability period. Price experiments: duplicate, change the price, and run them in different periods. ## Change these before you sell The duplicate inherits everything, which is the point and the risk: | Field | Why | | ----------------------- | ------------------------------------------------------------------------------------------------------------ | | **Name** | Two identically-named products confuse customers and your own order history. | | **URL slug** | Must be unique. | | **Price** | The most common thing left wrong. | | **Commands** | Almost always the reason you duplicated. A Gold Rank still running the Iron command is silent and expensive. | | **Game servers** | Especially for per-server variants. | | **Description** | Still describes the original's perks. | | **Image** | Inherited from the original. | | **Stock** | Inherited limits carry over. | | **Tier group** | Set it if this belongs to a ladder. | | **Availability period** | An expired original produces a product nobody can buy. | {% hint style="danger" %} **Test the duplicate before announcing it.** Buy it yourself and confirm the command that runs is the *new* one. An inherited command delivers the wrong package, and the first person to notice will be a paying customer. {% endhint %} There is no sandbox, so use a 100% [coupon](/marketing/coupons) or a [gift card](/marketing/gift-cards) rather than paying for it. Running the same product name across several servers? Set a **custom label** on each so they don't appear as identical rows in [Subscriptions](/orders-and-subscriptions/subscriptions) and [Orders](/orders-and-subscriptions/orders). # Bulk Assigning Products Grant a product to many customers at once, for compensation, giveaways, or migrating existing perks. Bulk Assign puts a product into many customers' inventories at once, without anyone paying for it: compensation after an outage, a giveaway, or perks people already own after a migration. To hand out value rather than a specific product, use [gift cards](/marketing/gift-cards) instead. *Dashboard → Content → Products → Bulk Assign. Needs `product_read`.*
The Bulk Assign Products form with a product, quantity and a list of customer identifiers.
## Assigning a product 1. Go to **Content → Products → Bulk Assign**. 2. Choose the **Product**. 3. Set the **Quantity** each customer should receive. Defaults to `1`. 4. Decide whether to tick **Skip Commands**. 5. Enter your **Customer IDs**. 6. Click **Bulk Assign**. ## The four fields | Field | What it does | | ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Product** | The product to grant. One product per run. | | **Quantity** | How many each listed customer receives. Applies to everyone in the list; you cannot vary it per person in a single run. | | **Skip Commands** | When ticked, the product lands in the customer's inventory but **its commands do not execute**. | | **Customer IDs** | Who receives it. Comma- or space-separated. Accepts **PayNow Customer IDs**, **Steam IDs**, or **Minecraft names**, and you can mix formats in one list. | Use **Bulk Load** to paste a large list of identifiers in one go, and **Clear** to empty the list. Individual customers and their inventories are covered in [Managing Customers](/customers/managing-customers). ## Deciding on Skip Commands By default, [commands](/integrations-and-commands/global-commands) run. Assigning a rank to 500 people executes the rank command 500 times. | Tick Skip Commands when… | Leave it unticked when… | | ---------------------------------------------------------------------------------------- | ------------------------------------------------ | | Players already have the perk in-game and you are only correcting their PayNow inventory | You want the perk actually applied in-game | | The command is destructive or non-idempotent (resets balances, overwrites inventory) | The command is safe to run | | Your server is offline and you do not want a queue of commands firing on boot | The server is up and you want immediate delivery | {% hint style="danger" %} **Test on yourself first.** Run a bulk assign with a single customer ID, your own, before running it against a real list. There is no bulk *un*-assign, and a command that behaves badly at scale is very hard to undo. Pay particular attention to commands that *set* rather than *add*. `setbalance 5000` run on 500 players will overwrite balances people earned or paid for. {% endhint %} Leave commands on for downtime compensation, giveaway prizes, staff perks and crowdfunding rewards. The exception is a post-migration perk restore, where players kept their in-game rank but PayNow has no record: tick **Skip Commands**, because the perk already exists in game. ## Before you run a large batch Check the identifier format. Minecraft *names* change; Steam IDs and PayNow Customer IDs don't, so prefer stable identifiers for a list assembled weeks ago. Confirm the quantity, which applies to everyone in the list, and confirm the product, because there's no undo. If commands will run, check your server is up. # Tier Groups Group products into a ranked ladder so customers upgrading between tiers pay only the difference. A tier group turns related products into a ladder, like Bronze / Silver / Gold, so a customer who already owns a lower tier pays only the **difference** when they move up. No separate upgrade products, no manual price maths. *Dashboard → Content → Tier Groups. Available on every plan including Free, for subscriptions and one-time products, across all game types including Minecraft.* Without one, a customer on Iron Rank who wants Obsidian pays the full Obsidian price having already paid for Iron. Most people don't, and you lose the upgrade. ## How it works When a customer owns a product from a tier group and buys a higher-tier product from the same group, PayNow charges only the difference instead of treating it as a new purchase. Downgrades work in reverse, without losing existing access. For subscriptions: | Change | What happens | | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Upgrade** | Applies immediately. The customer is charged the prorated difference for the remainder of the current billing period and receives the new tier straight away. | | **Downgrade** | Scheduled for the next renewal. They keep the current tier until the renewal date, then drop. | Customers see pending tier changes on the storefront, so a scheduled downgrade is never a surprise. For one-time purchases, pricing is cumulative: someone who bought Bronze and wants Gold pays the difference. You don't create Bronze→Gold, Silver→Gold and so on; the group derives the price from what the customer already owns. ## Tier order {% hint style="danger" %} **Tier rank comes from the order products appear on the Products page, not from price.** The first product listed is the lowest tier; the last is the highest. If your ladder is VIP → Elite → Premium, they must appear in that order on the Products page, whatever they cost. Get this wrong and upgrades charge the wrong amount, or a customer "upgrading" is silently processed as a downgrade. Reorder the Products page to change the ladder. {% endhint %} ## Creating a tier group 1. Go to **Content → Tier Groups**. 2. Click **Create** in the top right. 3. Enter a **Name**, for your reference only. Customers never see it. For example `Ranks`. 4. Click **Create**. The group appears in the list, empty. Products are assigned from each product's own page, not from here.
The Tier Groups page with a single group named Ravenhold Ranks.
## Assigning products 1. Open the product. 2. In the right sidebar, find **Tier Group**, labelled *"Used for cumulative pricing and subscription upgrades/downgrades"*. 3. Select the group from the dropdown. 4. Save. Repeat for every product in the ladder. **A product can belong to only one tier group.** For the rest of the product form, see [Creating a Product](/products/creating-a-product).
A product's edit page with the Tier Group selector in the right sidebar.
## Email verification Where customers sign in with just a username or in-game name and no Steam login, PayNow requires **email verification** before a tier change goes through. That stops someone who merely knows a player's name from interfering with their [subscription](/orders-and-subscriptions/subscriptions). Steam-login stores skip it; the identity is already verified. You don't configure this. PayNow applies it based on how customers authenticate. ## Custom storefronts A headless or custom storefront means implementing the upgrade and downgrade flows yourself against the Storefront API. See the [Tier Groups API reference](https://docs.paynow.gg/storefront-headless/storefront-api/tier-groups). # Revoking and Expiry Common questions about packages, covering revoking, expiry, subscriptions and deliverable actions. Quick answers about packages. For full setup instructions see [Creating a Product](/products/creating-a-product). ## How do I revoke a package from a customer? From the [customer's page](/customers/managing-customers#inventory), in the **Inventory** section. Two limits apply: * Expired packages cannot be revoked. The option is gone. * Non-expiring packages can be revoked, but only if an **On Expiry Action** is set. Without one, revocation won't go through. That second rule catches people out too late. If you sell a permanent package you might ever need to take back, for a chargeback say, set an **On Expiry Action** when you build the product. Adding it later doesn't help with purchases already made. ## What happens when a package expires? Any **On Expiry Actions** fire, removing roles, executing commands, and so on. **If no expiry action is set, nothing happens automatically.** The package shows as expired in the dashboard, but whatever it granted in game stays granted. That's the most common reason a "1 month VIP" package turns out to be permanent VIP. ## Can I create subscription-based packages? Yes. Set a billing cycle when configuring the product and customers are charged automatically at that interval. Not all payment methods support subscriptions, so check which are available for recurring billing when setting up the product. See [Settings](/store-settings/store). ## Does revoking a package remove a Discord role? Yes, if the role is set to be removed on expiry. **Revoking runs the On Expire stage.** That is the whole answer, and it's why you won't find a separate "on revoke" option anywhere. A manual revoke fires exactly what an expiry fires: your On Expire commands, and any Discord action with **Expiration** ticked under **Remove role access on**. So the role comes off if **Expiration** is ticked on that product's Discord action, and it is ticked by default. If someone unticked it, nothing removes the role, on expiry or on revoke. The same logic applies to commands. A product whose only removal command sits on On Refund leaves the customer holding their in-game rank after you revoke, because a revoke is not a refund. See [Commands & Placeholders](/integrations-and-commands/commands). What is separately documented is that a [ban](/customers/bans) on its own does not remove access to items the customer already bought — those have to be revoked manually. ## How do I assign multiple deliverable actions to a package? When creating or editing a package, scroll to **Deliverable Actions** and click **Add Action**. Actions stack, so you can combine a Discord role, a [game server command](/integrations-and-commands/global-commands), a [gift card](/marketing/gift-cards), and access to downloadable files. Ready-made templates: [Steam](/integrations-and-commands/steam-templates) · [Minecraft](/integrations-and-commands/minecraft-templates). Webhooks are configured separately on the [Webhooks](/integrations-and-commands/webhooks) page, not as a deliverable action. ## Need more help? Ask in the [PayNow Discord](https://discord.gg/paynow). # Orders Every transaction on your store, with the full detail behind each one. An order is a single completed transaction. When a customer says "I paid and nothing happened", the order timeline usually answers it in seconds. *Dashboard → Content → Orders. Needs `order_read`.*
The Orders list showing order IDs, customers, products, gross totals and statuses.

Total is the gross amount the customer paid, tax included — not the product's list price.

## Finding an order Search from the bar at the top left. You can also filter by **Customer**, **Product**, **Subscription ID**, **Status**, or whether the order is part of a **subscription**. Ask customers for the order ID first; it turns a ten-minute hunt into a single search, and it's on their receipt email. ## Inside an order Clicking an order opens a full breakdown. | Section | What it contains | | ----------------------- | --------------------------------------------------------------------- | | **Order Summary** | Total amount, currency, and subscription status if applicable. | | **Customer Card** | Username, avatar, and platform identifiers such as SteamID. | | **Order Details** | Creation and completion timestamps, Steam ID, customer info. | | **Billing Information** | Name, email, country. | | **Payment Info** | Method, card brand, last four digits, expiry, funding type, country. | | **Network Info** | IP address. | | **Line Items** | Products purchased, price, quantity. | | **Timeline** | Live status updates: creation, completion, and **command execution**. | Go straight to the timeline. Whether the command ran splits the problem in two. If it didn't, it's a delivery problem: check [Game Servers](/integrations-and-commands/game-servers) and the product's commands. If it did, it's a game-side problem: the plugin, permissions, or the player being offline. Hovering reveals more. The Steam and gift icons carry extra information, the gift box icon on a gifted product shows who sent it, and the Discord icon copies the customer's unique checkout URL, which is what you need when someone forgets to link their Discord after purchase.
An order detail view with the timeline showing creation, completion and command execution.

The timeline tells you whether delivery actually happened.

## Order statuses | Status | Meaning | What to do | | -------------- | ------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | | **Created** | Generated but not completed. | Usually an abandoned or in-flight payment. See [Abandoned Checkouts](/marketing/abandoned-checkouts). | | **Completed** | Processed successfully. | Nothing. | | **Refunded** | Money returned. | Consider whether to also revoke the item from the customer's inventory. | | **Chargeback** | The customer disputed the charge with their bank. | See below. | {% hint style="danger" %} **Chargebacks are not refunds.** The customer went to their bank rather than to you, and a pattern of them puts the store at risk: PayNow locks stores with an unacceptably high chargeback rate. Most are preventable. A customer who can't find how to cancel, or can't reach you, disputes instead. Two cheap defences: publish [checkout.paynow.gg/subscriptions](https://checkout.paynow.gg/subscriptions) where subscribers can cancel themselves, and monitor the support email on your store. When one happens, check whether the customer also holds active access, and consider a [ban](/customers/bans). {% endhint %} ## Refunding Refunding returns the money. It is a separate action from revoking: to take the item back, revoke it from their [inventory](/customers/managing-customers#inventory). Refunding one subscription payment does not stop future renewals either, so cancel the [subscription](/orders-and-subscriptions/subscriptions) as well. Revoking runs the product's **On Expire** stage, so your expiry commands and any Discord role set to come off on **Expiration** all fire. A refund on its own runs the **On Refund** stage, and only if you configured one. See [Commands & Placeholders](/integrations-and-commands/commands). You need the money to refund with. A refund comes out of your payout balance, so if the balance is lower than the amount you are returning, the refund will not go through until it is topped up by new sales. The customer sees the money back on their original payment method in 2 to 3 business days. ### Who decides a refund Customers are told to ask you first, and most refunds should be settled there. You can act immediately, and you can often fix the problem instead of refunding it. A request you decline or leave unanswered can go to PayNow. Under the [Creator Agreement](https://paynow.gg/legal/creator-agreement) you authorise PayNow, as merchant of record, to decide refund requests at its discretion and to handle disputes and chargebacks on your behalf. Where PayNow does not approve one, you can still refund the buyer yourself. Two things follow that are easy to miss: * **No fees come back on a refund.** The customer receives the full amount, but the platform fee and the gateway's processing fee are both kept. A refund costs you the sale plus every fee that was already taken from it. The per-order fee breakdown is in [Transactions](/payments-and-payouts/transactions). * **Problems with the Item itself are yours to resolve with the buyer.** Delivery, access and whether the product does what you said are all things only you can fix. Point customers at [Refunds and Cancellations](/for-your-players/refunds-and-cancellations) so they arrive with an order ID. A purchase delivered to the wrong game account does not need a refund. Revoke it from that customer's [inventory](/customers/managing-customers#inventory) and assign it to the right one. # Subscriptions View and manage recurring billing, including renewals, cancellations and what customers can do themselves. Every purchase of a subscription-type product creates a subscription: an agreement to bill the customer again on a schedule. Each payment it generates appears in [Orders](/orders-and-subscriptions/orders), and a free period before billing starts is a [trial](/orders-and-subscriptions/trials). *Dashboard → Content → Subscriptions. Needs `subscription_read`.*
The Subscriptions list showing subscription ID, customer, product, price and status.
## Reading the list | Column | What it tells you | | ------------ | ------------------------------------------------------------------------------------------------------------------------------ | | **ID** | The subscription identifier. Quote this to support; it's the fastest way to get an answer about a specific recurring customer. | | **Customer** | Who is being billed. | | **Product** | What they subscribed to. | | **Price** | The recurring amount. | | **Status** | Active, cancelled, or otherwise. A cancelled subscription usually remains active until the end of the paid period. | The smaller text under the package name is the product's **custom label**, set on the [product](/products/creating-a-product). It lets communities running the same rank name across several servers tell them apart, for example two `Gold Rank` products labelled *Survival* and *Creative*. ## What customers can do themselves Subscribers manage their own renewals at [checkout.paynow.gg/subscriptions](https://checkout.paynow.gg/subscriptions), and can cancel there without contacting you. {% embed url="" %} Link it directly: pin it in Discord, put it in your store's footer, include it in receipt emails. A subscriber who can't find how to cancel is a candidate for a chargeback instead, which costs you the revenue and counts against your store's chargeback rate. A cancellation costs you nothing but the renewal. ## Cancellation versus refund Different actions, different outcomes, and confusing them causes angry tickets. | Action | Effect on access | Effect on money | | ---------- | ---------------------------------------------------------- | ------------------------------- | | **Cancel** | Access continues to the end of the paid period, then stops | Nothing returned | | **Refund** | Depends on how you handle delivery | Money returned for that payment | Cancelling doesn't refund the most recent charge, and refunding doesn't stop future renewals. A customer who wants out entirely and wants their money back needs both. ## Failed renewals A renewal can fail: an expired card, insufficient funds, a bank declining a recurring charge. The subscription doesn't silently vanish. It stays **active** and the list shows a **Retrying** badge instead of the status, with the next retry date on hover. The subscription's own page shows **Next attempt at** and **Attempt count**. PayNow retries a failed renewal several times before giving up. Read **Attempt count** on the subscription rather than guessing where in that sequence a customer is. Most failures are an expired card, which no number of retries will fix, so a message to the customer beats waiting it out. ## Two questions that come up **A customer says they were charged several times in a month.** Check the product's billing period first. A weekly product bills every week, and most "charged multiple times" reports are a weekly subscription read as a monthly one. Genuine duplicates show as two separate subscriptions in the list. **Stopping duplicate or downgrade purchases.** A per-customer stock limit on the product stops a customer holding more than one of it, including buying a cheaper tier alongside an upgraded one. See [Stock](/products/creating-a-product#stock). # Trials Give customers a free period before billing starts, with cooldown rules to stop trial farming. A trial gives a customer full access to a [subscription](/orders-and-subscriptions/subscriptions) product for a set period before the first charge. If they don't cancel, it converts to a paid subscription automatically. *Dashboard → Content → Trials. Needs `trial_read`. Subscription products only.* ## Enabling trials on a product 1. Go to **Content → Products → *****(your product)***. 2. Under **Lifetime → Trial configuration**, enable **Allow Trials**. 3. Set the **Trial Period**, for example 7 days. 4. Optionally enable **New Customers Only**. 5. Optionally configure cooldowns (below). 6. Save. Access begins as soon as the trial starts. If the customer doesn't cancel before the end date, the subscription converts to paid automatically at the listed price. The rest of the product form is covered in [Creating a Product](/products/creating-a-product). ## Trial settings | Field | What it does | | ----------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | | **Allow Trials** | Enables trials for this product. | | **Trial Period** | Length of the trial, in days, weeks or months. | | **Revoke immediately when canceled** | Removes access the moment a customer cancels during the trial, rather than letting it run to the scheduled end. | | **New Customers Only** | Only customers with **no prior orders of this product** can start a trial. | | **Customer must have no orders in the last X days** | Store-wide cooldown. Blocks anyone who bought **anything** from you recently. | | **Allow Repeat Trials** | Permits a second trial after a cooldown. | | **Customer must not have ordered the product in the last X days** | Per-product cooldown. Only applies when **Allow Repeat Trials** is on. | Leaving **Revoke immediately when canceled** off is more generous, but someone can then start a trial, cancel straight away, and keep access for the full period. Turn it on where the perk has real value. ### Choosing cooldown settings The cooldown fields stop trial farming, where customers cycle free periods instead of paying. How aggressive to be depends on what you're selling. | Your situation | Suggested setup | | ---------------------------------------- | ---------------------------------------------------------------------------- | | Standard rank trial | **New Customers Only** on, repeat trials off. Simplest and hardest to abuse. | | Win-back campaign for lapsed subscribers | Repeat trials on, per-product cooldown of 90+ days. | | High-value perk | New Customers Only on, **Revoke immediately when canceled** on. | | Low-risk cosmetic | Repeat trials on, short cooldown. Abuse costs you little. | ## How a trial runs A trial begins at checkout once the customer opts into the subscription, and gives them the product's full subscription benefits. Cancel during the trial and access is revoked immediately if the revoke toggle is on, otherwise at the scheduled end. Once cancelled or expired, access is removed and billing stops. ## Managing trials **Content → Trials** lists every trial: active, completed and cancelled.
The Trials list showing trial ID, customer, product, status and start and end dates.
| Column | Meaning | | ------------- | ----------------------------------------- | | **Trial ID** | Unique identifier. Quote this to support. | | **Customer** | Who started it. | | **Product** | What is being trialled. | | **Status** | Created, Active, Canceled or Completed. | | **Created** | When the trial record was made. | | **Starts At** | When access begins. | | **Ends At** | When it converts to paid, or is revoked. | Filter using the controls in the top right: **Checkout ID**, **Subscription ID**, **Customer**, or **Status**. Clicking a trial opens its detail view, where you can **end the trial early**. You can also end one early from the related [subscription](/orders-and-subscriptions/subscriptions). ## Checking whether trials are working Check [Analytics → Recurring Payments](/analytics/analytics) after your first month. | What you see | What it usually means | | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | High trial starts, low conversion | The perk isn't compelling, or the trial runs long enough that the novelty wears off before the charge. Try shortening it. | | Low trial starts | Customers can't find it, or don't trust it. Make the free period explicit on the storefront. | | Good conversion but churn at month two | The trial oversold what the product delivers. | # Customers Everyone who has interacted with your store, and how to look them up. The customer list is your lookup tool. Most visits start with a support ticket, a giveaway winner, or a name you want to check before banning. *Dashboard → Content → Customers. Needs `customer_read`.*
The Customers list with the copy icon beside a customer ID highlighted.
The icon to the right of any ID copies it. Use it rather than retyping: a mistyped 17-digit Steam ID or UUID silently looks up the wrong person, or nobody. ## What you can do here | Task | Guide | | ----------------------------------------------------------- | -------------------------------------------------------------- | | Look at one customer's history, inventory and subscriptions | [Managing Customers](/customers/managing-customers) | | Add someone who has never logged in | [Creating a Customer Manually](/customers/creating-a-customer) | | Stop someone buying | [Bans](/customers/bans) | | Grant a product to many people at once | [Bulk Assigning Products](/products/bulk-assigning-products) | Open the record before you act on it. For a refund or chargeback, check whether they still hold active access first. Before a ban, confirm you have the right person. ## Identifiers Customers are identified by a platform-specific external ID, not by name. | Platform | Identifier | | ------------------- | ---------- | | Rust / Steam titles | SteamID64 | | Minecraft | UUID | {% hint style="warning" %} **Names change; IDs do not.** Search and record by platform ID wherever you can. This matters most for bans and for [bulk assignment](/products/bulk-assigning-products), where a list of names collected weeks ago will have drifted. {% endhint %} # Managing Customers The customer detail page, covering stats, inventory, orders, subscriptions, metadata and bans. Everything about one person comes together on the customer detail page. If you handle support, this is where you'll live. *Dashboard → Content → Customers → (a customer). Needs `customer_read`.* ## Header | Field | What it is | | ----------------- | --------------------------------------------------------------------------- | | **Profile** | Username and profile link, where available. | | **External ID** | Platform-specific identifier: **SteamID64** in Rust, **UUID** in Minecraft. | | **First Seen At** | When they first appeared on your store. | ### Stats | Stat | What it means | | ------------------------------ | ---------------------------------------------------------- | | **Total Spent in Store (Net)** | Total spend after fees and refunds. | | **MRR** | Monthly recurring revenue from their active subscriptions. | | **Total Payments** | Count of completed payments. | | **Active Subscriptions** | How many subscriptions they currently hold. | Read these before answering a complaint: a long-tenured customer with real MRR and someone disputing their first $2.99 deserve different answers. ### Actions Three buttons: **Ban**, **Manage Tokens** and **Edit Customer**. Ban stops them purchasing and is covered below. Edit Customer updates their **name** and **platform ID** (SteamID64, UUID), which is how you correct a mistyped one.
A customer detail page showing profile, external ID, and the stats row.
## Inventory Everything the customer owns or previously owned, active and expired, one-time and subscription. Inventory is about access; [Orders](/orders-and-subscriptions/orders) is about transactions. An expired package shows as **Expired** here while the original order stays in Orders permanently. "Do they still have VIP?" is answered here. **Assign Product** manually grants a product. For many customers at once, use [Bulk Assigning Products](/products/bulk-assigning-products). ### Package action buttons Which buttons appear depends on the package's state. | Button | What it does | | ---------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | **Discord** | Opens the Discord Linking UI so you can attach a Discord User ID to that inventory item. | | **Info (ℹ️)** | Opens the Command UI: every command tied to the package, which game server it ran on, the exact command, and its execution status. | | **Revoke (red)** | Removes the active item, taking away access. | Reach for **Info** before you go looking at server logs. **Revoking runs the product's On Expire stage.** It is the expiry path, triggered by hand, so whatever you configured to happen on expiry is what happens on revoke. See [Commands & Placeholders](/integrations-and-commands/commands). {% hint style="warning" %} **Revoke has two limits, and both follow from that.** An already-expired package can't be revoked; the button is gone, because the expiry already ran. And a non-expiring package can only be revoked if it has an **On Expiry Action** set, since without one there is nothing for revoke to run. {% endhint %} ## Orders Every order this customer has placed: **Order ID**, **Product Name**, **Price**, **Status** and **Date**. Statuses are **Created**, **Completed** and **Chargeback**. Filter with the control in the top right; click any order for the full breakdown in [Orders](/orders-and-subscriptions/orders). ## Subscriptions All subscriptions, active and cancelled: **Subscription ID**, **Product**, **Amount**, **Status**, **Billing Period** and **Created**. Filter by **Active**, **Canceled** or **Created**; click through for detail in [Subscriptions](/orders-and-subscriptions/subscriptions). ## Metadata Key-value pairs attached to the customer, for integrations, custom commands and tracking. Most often used to link external accounts like Discord. | Field | Example | | --------- | ------------------------------ | | **Key** | `DiscordID`, `DiscordUsername` | | **Value** | The corresponding data | Click **Add Field** to add one. To remove a field, clear both Key and Value and press **Update**. There is no delete button. ## Banning a customer 1. On the customer page, click **Ban**. 2. Enter a **reason**, internal only and never shown to the customer. 3. Optionally set an **expiration date**. Leave blank for a permanent ban. 4. Choose the **identity type** to ban: | Identity | Bans | Notes | | ----------------- | --------------------------------- | --------------------------------------------------------------------------------------------------- | | **Customer** | The specific account | The usual choice. | | **Customer Name** | Anyone using that name | **Not recommended.** Names change, so this both misses the target and catches innocent people. | | **Steam ID** | Their Steam account | Strong. Survives name changes. | | **IP Address** | Everyone on that IP | Use sparingly. Shared and dynamic IPs catch bystanders. | | **Payment Email** | The email on their payment method | Stops them making a new account and paying with the same card. Works across all payment processors. | 5. Click **Create**. Use **Add Identity** to ban several identifiers at once. A large red banner then appears at the top of their page with the ban ID and a **View Ban** button. {% hint style="danger" %} **Banning stops future purchases. It does not remove existing ones.** A banned customer keeps everything they already bought unless you revoke it from their Inventory. A chargeback needs two actions: ban them, and revoke the item. Doing only the first leaves them with the goods and none of the cost. {% endhint %} ### Viewing, updating or removing a ban Click **View Ban** in the red banner. In **Edit Ban** you can update the reason, expiration and identities, or click **Unban**. Bans with an expiration date lift automatically. More in [Bans](/customers/bans). # Creating a Customer Manually Add someone to your store before they have ever logged in, for giveaways, coupons and comped access. Customers appear the first time they visit your store. Sometimes you need one to exist before that, usually because you want to give them something. *Dashboard → Content → Customers → **New Customer**. Needs customer write access.* The common case is a giveaway winner who has never logged in, so there is no record to attach anything to. Creating the customer first gives you something to point a [coupon](/marketing/coupons) or an assigned product at. The same applies when you comp a creator before they visit, pre-register staff so their roles and perks are ready, restore a player after a migration who owns perks in game but has no PayNow record, or work a support case where you have the platform ID but no account. ## Creating one 1. Click **Create** in the top right of the Customers page. 2. Enter their **Steam64ID** (or the platform ID appropriate to your store). 3. Optionally enter a **name**. 4. Click **Create**.
The New Customer dialog with fields for a platform ID and an optional name.

The name is optional — the platform ID is what matters.

The name is cosmetic; the platform ID identifies the person. Add one anyway, so you aren't reading a list of bare numeric IDs six months from now. {% hint style="warning" %} **Get the ID right.** The platform ID is the record. A typo creates a customer profile for somebody else entirely, and if you then assign a product to it, a stranger receives the prize. Copy and paste it. Do not retype a 17-digit Steam ID or a UUID from a screenshot. If you get it wrong, **Edit Customer** on their detail page fixes it. {% endhint %} ## After creating | Next step | Guide | | ------------------------------- | ------------------------------------------------------------------------- | | Give them a discount | [Coupons](/marketing/coupons) | | Grant a product directly | [Managing Customers → Inventory](/customers/managing-customers#inventory) | | Grant to several people at once | [Bulk Assigning Products](/products/bulk-assigning-products) | | Give them store credit | [Gift Cards](/marketing/gift-cards) | When the person signs in with the matching platform identity, they land on the record you created, and whatever you attached is waiting. There is no merge step and no duplicate, provided the ID was correct. # Bans Stop someone purchasing from your store, by account, name, Steam ID, IP or payment email. A ban prevents someone buying from your store. It does not take away what they already bought. *Dashboard → Access → Bans. Needs `ban_read`.* ## Creating a ban 1. Go to **Access → Bans**. 2. Click **Create**. 3. In **Create a Ban**: * Enter a **reason**. Internal only, never shown to the customer. * Optionally set an **expiration date**. Blank means permanent. * Select the **identity type**. * Click **Add Identity** to ban several identifiers at once. 4. Click **Create**. The Bans page does not pre-fill customer information, so you have to type the identifier yourself. Banning from the [customer's own page](/customers/managing-customers#banning-a-customer) is usually easier. ## Identity types | Type | Bans | Notes | | ----------------- | -------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | **Customer** | A specific customer account | The normal choice. | | **Customer Name** | Anyone using that name | **Not recommended.** Names change, so it misses the target and catches innocent people. | | **Steam ID** | Their Steam account | Strong. Survives name changes. | | **IP Address** | Everyone on that IP | Use sparingly. Shared and dynamic IPs catch bystanders. | | **Payment Email** | The email attached to a payment method | Stops a banned customer creating a new account and paying with the same card. **Works across all payment processors.** | Payment Email is the one that stops repeat offenders. Account and Steam bans are defeated by making a new account; the payment method is harder to change, and someone committing chargeback fraud usually has one card. For a serious case, add several identities to one ban: the customer, their Steam ID, and their payment email. ## What a ban does and does not do | | | | ---------------------------------------------------------------- | -------------------------------------------------------------------------------- | | ✅ Blocks new purchases | | | ✅ Shows a red banner on their customer page for staff | | | ✅ May show them an error at checkout, depending on your template | | | ❌ **Does not revoke existing purchases** | Revoke manually from their [inventory](/customers/managing-customers#inventory) | | ❌ **Does not cancel active subscriptions** | Cancel them manually in [Subscriptions](/orders-and-subscriptions/subscriptions) | | ❌ **Does not apply to other PayNow stores** | Bans are per store | {% hint style="danger" %} **A ban on its own leaves an active subscriber still being billed and still holding their perks.** A chargeback case usually needs three actions: ban the customer, ideally including their payment email; revoke the items from their inventory; and cancel any active subscriptions. Doing only the first is the common mistake, and it leaves them with everything. {% endhint %} ## Viewing and managing bans The Bans page lists banned identities, the reason, the ban ID, and when it was last updated. Filter using **Ban Identifier** to search for a customer, Steam ID or IP.
The Bans page listing banned identities with reasons and ban IDs.
To change or lift a ban, find it in the list and click **View Ban**. In **Edit Ban** you can modify the reason, expiration or identities, or click **Unban** and confirm. Click **Update** to save. Bans with an expiration date lift automatically when they expire. # Webstore Your PayNow-hosted storefront, its address, its custom domain, its templates and its modules. The Webstore page controls the storefront PayNow hosts for you: where it lives, what it looks like, and which dynamic components appear on it. **Go to Webstore** in the top right opens your live storefront. *Dashboard → Appearance → Webstore. Needs `webstore_read`.*
The Webstore page showing store details, custom domain, templates and modules sections.
## Store details Your **slug** is a unique subdomain identifying your store. It gives you an address of the form: ``` .paynow.store ``` You can change it with **Change Slug**. {% hint style="danger" %} **Changing your slug changes your storefront address.** Discord pins, social posts, in-game messages, YouTube descriptions and bookmarks all point at the old one. If you want a different address, set up a custom domain instead and leave the slug alone. {% endhint %} ## Custom domain Point your own domain at your storefront, `store.yourcommunity.com` for example. Both a root domain and a subdomain work. This is a **Pro Plan** feature; on other plans the section is visible but cannot be activated. 1. Enter your registered domain in the **Domain** field. 2. Click **Activate Custom Domain**. 3. Follow the DNS instructions shown. 4. Wait for **Status** to change from *Inactive* to active. DNS changes are not instant; give propagation time before assuming something failed. A custom domain buys more than vanity. Customers are more willing to enter card details on an address they recognise as yours, and you can change hosting later without changing it. ## Templates Templates handle the appearance of your webstore. The table lists each one with when it was created and updated, and which is **Active**. Only one is live at a time. **Browse Templates** starts you from a pre-built design, and **New Custom Template** builds your own. See [Templates](/your-webstore/templates) for the full workflow and [Editing Template Files](/your-webstore/editing-template-files) for the Twig reference. ## Modules Modules display live data rendered into your storefront, rather than static content you maintain by hand. The table lists each module's header, type, when it was updated, and whether it is enabled. | Module | Shows | | --------------------- | ---------------------------------------------------------- | | **Featured Product** | A single promoted product | | **Payment Goal** | Progress toward a revenue target over a period | | **Recent Payments** | Recent orders, with configurable detail | | **Top Customer** | Customers ranked by spend, average spend, or payment count | | **Gift Card Balance** | A gift card's code, balance, starting balance and expiry | | **Text Box** | Free HTML content under a header | Click **Create** to add one. Each module has a **header** plus type-specific settings: Payment Goal takes a **Goal Target**, a **Period** and bar options, while Top Customer takes a **Field**, a **Period** and a customer limit. Top Customer publishes spend-related data about your players, so check the **Display spend amount** option matches what your community expects. Modules render wherever your template outputs them. See [Editing Template Files](/your-webstore/editing-template-files#modules). # Templates Create, upload, preview and activate webstore templates, including running an existing Tebex template through compatibility mode. A template is the complete design of your storefront. You can have as many as you like; one is **Active** at a time. *Dashboard → Appearance → Webstore → Templates. Needs `webstore_read` to view.* ## Getting a template | Route | Use when | | ----------------------- | -------------------------------------------------------------------- | | **Browse Templates** | You want something that works immediately. Start here. | | **New Custom Template** | You are building a design yourself. | | **Upload Template** | You have a template file already, including one exported from Tebex. | | **Duplicate Template** | You want to change a working template without risking it. | Duplicate before editing a live template: duplicate, edit the copy, preview, set active. It costs one click and means a broken edit never reaches customers. ## The template page Opening a template shows its **ID** (copyable, and worth quoting to support) and its settings.
A template detail page with the Actions menu open showing Set as Active, Live Template Preview, Upload, Export and Duplicate.
### General | Field | What it does | | ---------------------- | ------------------------------------------------------------------------------------------------------------ | | **Name** | A human-readable identifier for your template. Internal only; customers never see it. | | **Compatibility Mode** | Which platform's template conventions this template follows. Set to **Tebex** to run a Tebex-style template. | ### Actions | Action | What it does | | ------------------------- | ----------------------------------------------------------------------------------- | | **Set as Active** | Makes this the live storefront design. Takes effect immediately. | | **Live Template Preview** | View the template without making it active. Use this before every activation. | | **Upload Template** | Import template files. | | **Export Template** | Download the template. It is your backup, and how you move a design between stores. | | **Duplicate Template** | Copy it. Use before editing anything live. | | **Update** | Save your changes. | | **Delete** | Remove the template. Not reversible. | {% hint style="warning" %} **Export before you delete, and export before major edits.** Export is the only backup mechanism. There is no version history to roll back to. {% endhint %} ## Tebex compatibility mode If you are [migrating from Tebex](/getting-started/migrating-from-another-platform), compatibility mode lets an existing Tebex template run on PayNow with minimal rework. Setting it reveals a **Tebex Compatibility Options** section: | Option | What it does | | ---------------------- | ------------------------------------------------------------------- | | **Index Description** | Rich-text content shown on the index (home) page. | | **Tebex Display Type** | How products are displayed within categories, for example `images`. | | **CMS Pages** | Additional content pages carried over from the Tebex structure. | Compatibility mode is a migration aid, not a permanent home. A native PayNow template gives you the full [variable set](/your-webstore/editing-template-files#variables) and [modules](/your-webstore/webstore#modules), so plan to move across once you are settled. ## A safe workflow for changing your storefront 1. **Duplicate** the active template. 2. Edit the duplicate. See [Editing Template Files](/your-webstore/editing-template-files). 3. **Live Template Preview** the duplicate and click through every page: home, a category, a product, cart, subscriptions, completion. 4. **Export** it as a backup. 5. **Set as Active**. 6. Load your real storefront in a private window and confirm. Keep the previous template. It is your rollback. # Editing Template Files Webstore templates are Twig, and this is the reference for routes, template files, variables and modules. Hosted webstore templates use [**Twig**](https://twig.symfony.com/). Each customer-facing route renders a specific template file, and each file receives a set of variables. *Dashboard → Appearance → Webstore → Templates → (a template) → files.* The developer docs at [docs.paynow.gg/hosted-webstores](https://docs.paynow.gg/hosted-webstores/routes) are the canonical reference, and are updated first. {% hint style="danger" %} **Duplicate before you edit.** There is no version history and no rollback. Your only backup is **Export Template**. Edit a duplicate, preview it, then set it active. See [Templates](/your-webstore/templates). {% endhint %} ## Routes and their template files | Route | Method | Template file | Renders | | -------------------------- | ------ | -------------------- | ------------------------------------------- | | `/` | GET | `index.html` | The storefront homepage | | `/products` | GET | `category.html` | Product listing, optionally filtered by tag | | `/products/{product.slug}` | GET | `product.html` | A single product's detail page | | `/cart` | GET | `cart.html` | The shopping cart | | `/subscriptions` | GET | `subscriptions.html` | The customer's subscriptions | | `/complete` | GET | `complete.html` | Confirmation after a successful transaction | | `/legal/terms-of-service` | GET | None | Terms of Service | | `/legal/user-agreement` | GET | None | User Agreement | | `/legal/privacy` | GET | None | Privacy Policy | ### Action endpoints These accept POSTs and do not render a template. Point forms and buttons at them. | Endpoint | Method | Does | | ----------------------------------------- | ------ | --------------------------------------------- | | `/products/{product.slug}/checkout` | POST | Starts checkout for one product | | `/cart/add/{product.slug}` | POST | Adds to cart | | `/cart/set/{product.slug}` | POST | Modifies or removes a cart line item | | `/cart/empty` | POST | Clears the cart | | `/cart/checkout` | POST | Checks out the cart | | `/auth/sign-in` | POST | Signs the customer in, with optional redirect | | `/auth/sign-out` | POST | Signs the customer out | | `/subscriptions/{subscription.id}/cancel` | POST | Cancels a subscription | Wire the cancel endpoint into your subscriptions page, or link customers to [checkout.paynow.gg/subscriptions](https://checkout.paynow.gg/subscriptions), rather than building your own cancellation flow. A customer who cannot find how to cancel disputes the charge instead. See [Subscriptions](/orders-and-subscriptions/subscriptions). ## Variables ### Global, available in every template | Variable | What it holds | | ---------------------- | --------------------------------------------------------------- | | `store` | Your store's details | | `webstore` | Webstore configuration | | `cart` | The current customer's cart | | `navlinks` | Your configured [navlinks](/your-webstore/navlinks) | | `tags` | Your [tags](/your-webstore/tags) | | `customer` | The signed-in customer, if any | | `request` | The current request | | `notification` | Any notification to surface to the customer | | `currency` | The active display currency | | `available_currencies` | Currencies the customer can switch to | | `modules` | Configured [modules](/your-webstore/webstore#modules), rendered | | `favicon` | The store favicon | Always check `customer` before using it. It is empty for signed-out visitors, and a template that assumes a signed-in customer breaks the storefront for everyone browsing anonymously, which is most of your traffic. ### Page-specific | Template | Variable | What it holds | | -------------------- | ----------------------- | -------------------------------------------- | | `index.html` | `products` | All available products | | `category.html` | `products` | Products matching the active tag | | | `activeTag` | The tag currently filtering | | | `activeTags` | All active filtering tags | | | `activeNavlink` | The active navigation link object | | `product.html` | `product` | The selected product | | | `available_gameservers` | Optional gameserver choices for the customer | | `complete.html` | `complete` | Information about the completed order | | `subscriptions.html` | `subscriptions` | The customer's subscriptions | `available_gameservers` is how a customer chooses which server their purchase applies to. Leave it out of `product.html` in a multi-server store and purchases land on the wrong server, which generates refund requests. See [Game Servers](/integrations-and-commands/game-servers). ## Modules Modules are rendered wherever you output the `modules` variable: This auto-populates every module you have configured. The `raw` filter is required; without it the HTML is escaped and customers see markup instead of content. Each module type has its own file, so you can override the markup individually: | Module | File | | ----------------- | ------------------------------ | | Featured Product | `module.featured_product.html` | | Payment Goal | `module.payment_goal.html` | | Recent Payments | `module.recent_payments.html` | | Top Customer | `module.top_customers.html` | | Gift Card Balance | `module.giftcard_balance.html` | | Text Box | `module.text_box.html` | The Top Customer file is plural while the module name is singular. That's not a typo here. Configuration lives in the dashboard, not the template: Payment Goal's **Goal Target** and **Period**, Top Customer's **Field** and limit. See [Webstore → Modules](/your-webstore/webstore#modules). ## Before activating any template change Click through all of these in **Live Template Preview**: * Homepage * A category page, with a tag filter applied * A product page, signed **out** * A product page, signed **in** * Cart, with and without items * The subscriptions page * The completion page Signed-out states are the ones that break, because they are the ones you never look at while developing. # Tags Group products into categories customers can browse, and the prerequisite for navlinks. Tags are subcategories. A customer clicking a tag sees every product carrying it, which is how a growing catalogue stays navigable. They are also the prerequisite for [navlinks](/your-webstore/navlinks), which are built from tags. *Dashboard → Appearance → Tags. Needs `tag_read`.* ## Creating a tag 1. Go to **Appearance → Tags**. 2. Click **Create** in the top right. 3. Fill in **Name**, **Slug** and **Description**. | Field | What it does | | --------------- | -------------------------------------------------- | | **Name** | What customers see. | | **Slug** | Used in the storefront URL for that tag's listing. | | **Description** | A rich-text description of the tag. | Whether the description appears is up to your template. It's available to render as the tag or [navlink](/your-webstore/navlinks) description, so a category page can carry a line of copy above its products. A template that never outputs it means the field is stored and never shown. See [Editing Template Files](/your-webstore/editing-template-files).
The New Tag form with name, slug and description filled in.
To apply a tag, edit the product, select the tags on the right-hand side, and save. A product can carry several tags. {% hint style="warning" %} **Avoid changing a slug after launch.** The slug appears in the storefront URL for that tag's listing, so editing it breaks bookmarks and any link you have already shared. {% endhint %} ## Designing a tag structure Tags are cheap to create and expensive to reorganise. Decide early which axis you organise along: | Axis | Example tags | Good when | | ---------------- | -------------------------------- | -------------------------------------- | | **Product type** | Ranks, Currency, Kits, Cosmetics | One server, varied catalogue | | **Server** | Survival, Creative, Modded | Several servers, similar catalogue | | **Both** | Survival Ranks, Creative Ranks | Several servers *and* varied catalogue | Don't create a tag per product. A tag holding one item is a product page with extra steps. ## Tags are not tier groups Easy to confuse, different jobs. **Tags** are presentational: how products are grouped and displayed. [**Tier Groups**](/products/tier-groups) are behavioural: how products relate to each other so upgrades charge only the difference. Putting Iron, Gold and Obsidian in a *tag* called Ranks makes them appear together; it does **not** make upgrading between them work. You need both. ## Tags in templates Custom storefronts get `tags` as a global variable, and `category.html` receives `activeTag` and `activeTags` for the current filter. See [Editing Template Files](/your-webstore/editing-template-files). # Navlinks Turn tags into navigation bar buttons, reorder them, and nest them into dropdowns. Navlinks are the buttons on your storefront's navigation bar. Each one points at a [tag](/your-webstore/tags), giving customers one-click access to a category. You need at least one tag before you can create a navlink, since there is otherwise nothing to point a button at. *Dashboard → Appearance → Navlinks. Needs `tag_read` (navlinks share the tag permission).* ## Creating a navlink 1. Go to **Appearance → Navlinks**. 2. Click **Create** in the top right. 3. Select the tag you want to appear as a button. Visit your storefront to see it.
The Navlinks page showing Ranks, Currency and Servers, with Survival and Creative nested under Servers to form a dropdown.
## Reordering Click and drag the movement icon on the left of a navlink to change its position. The order here is the order on your storefront. The first item gets disproportionate clicks, so check [Analytics](/analytics/analytics) for which category actually earns and lead with that. ## Making a dropdown Drag a navlink's movement icon **below and slightly to the right** of another navlink. It nests underneath, and the topmost link becomes the dropdown parent. A **Servers** dropdown holding Vanilla, Modded and Creative beats three top-level buttons crowding the bar.
A navlink being dragged below and to the right of another to create a dropdown.

Drag below and slightly right to nest.

## How many is too many Keep the top level short, around five items. Past that the bar wraps or scrolls on smaller screens and stops functioning as navigation. A structure that works for most stores: ``` Ranks Currency Servers ▾ Cosmetics Support ├ Survival ├ Creative └ Modded ``` {% hint style="warning" %} **Check your storefront on a phone.** A large share of game store traffic is mobile, and a navigation bar that looks fine at 1440px can be unusable at 390px. Nest aggressively rather than adding another top-level button. {% endhint %} ## Navlinks in templates Custom storefronts receive `navlinks` as a global template variable, and `category.html` gets `activeNavlink` for the current selection. See [Editing Template Files](/your-webstore/editing-template-files). # Branding Put your logo and colours on your store and checkout so customers recognise where they are. Branding matches your store and checkout to the community your customers came from. Someone who arrives from your Discord and finds a generic checkout hesitates, and hesitation at the card form costs you the sale. *Dashboard → Appearance → Branding. Needs `branding_update`.* ## Logos Your logo appears in several places: your store banner on the default theme, the **View Cart** button, and elsewhere. It accepts **PNG, JPEG, SVG, WEBP or GIF**, at a recommended width of **at least 256px**.
The Branding page showing the Logos section with a logo uploaded.
Use the logo your community already knows, the one on your Discord and your server banner. Recognition is the point, and a newly-designed logo that exists only on the store does the opposite. Prefer **SVG**, which stays sharp at every size. Otherwise use a PNG with a transparent background, comfortably wider than 256px. ## Checkout Branding Checkout Branding extends branding into the checkout itself, with custom fonts, a custom colour scheme and a custom background image. It requires the **Business** plan, which the dashboard badges as *Business Plan Feature*. Upgrade from [Billing](/payments-and-payouts/billing). Checkout is the last screen before payment, and the one that looks least like your community by default.
The Checkout Branding panel unconfigured on the left and fully configured on the right.

Checkout Branding unconfigured (left) and configured with a custom font, colours and background image (right).

### Getting the colours right Pull the exact hex values from your Discord theme or website rather than eyeballing them. Keep the background quiet: a busy image behind a payment form reads as untrustworthy, while something dark and low-contrast works. Test on a phone, because background images crop unpredictably at narrow widths. {% hint style="warning" %} **Check contrast before you save.** A dark scheme that renders body text at low contrast costs you more than the branding gains. The price and the pay button have to be unmistakable, on desktop and on mobile. {% endhint %} ## Branding versus templates **Branding** covers your logo, colours, fonts and checkout appearance, and applies across your store and checkout without touching code. [**Templates**](/your-webstore/webstore) are the full storefront design, edited as Twig files. Start with Branding; reach for a template only when you need layout changes Branding cannot express. # Sales Run a time-limited discount across your catalogue, specific products, or a tag. A sale discounts products automatically for everyone, with no code to enter. Use it for holidays, launches and events. *Dashboard → Marketing → Sales. Needs `sale_read`.* The Sales page lists every sale, past and present, with its name, status, discount, end date and last update. Click **Create** to create one. ## Creating a sale Five sections, three of them optional. **Sale Details** is the sale's name. It is visible to customers on the checkout page, so make it readable: `Summer Siege` or `Black Friday`, not `test2-final`. **Sale Lifetime** takes optional start and end dates. Set an end date. A sale with no end is a price cut, and it trains your community to expect the discounted price permanently. **Discount Details** is **Percentage** or **Fixed**, then the amount, then a **Discount Duration**: **Apply once**, **Forever**, or **Multiple subscription renewals** (which asks for a number of renewals). **Sale Application** optionally limits the sale to specific products or tags. Leave it empty to apply the sale to everything. Applying by [tag](/your-webstore/tags) is usually easier: tag your seasonal items once and every future sale can target that tag. **Redeem Requirements** optionally requires a minimum order value before the discount applies, $5 for example. A minimum raises average order value: a customer at $4.20 will often add something to cross it.
The sale creation form showing name, lifetime, discount type and application.
Once created, the sale's page lists every order it was applied to. That is how you judge whether it worked. ## Sales versus coupons | | Sale | [Coupon](/marketing/coupons) | | ------------------------- | -------------------------- | ------------------------------------- | | Who gets it | Everyone | Whoever has the code | | Requires a code | No | Yes | | Good for | Site-wide events, holidays | Giveaways, targeted offers, win-backs | | Visible on the storefront | Yes | No | They can interact. Check your **promo code stacking** setting in [Settings](/store-settings/store), and note that coupons have an **Apply before sales** option that changes the calculation order. ## Making a sale work Check **Popular Times of Day** in [Analytics](/analytics/analytics) and launch just before your peak, not at whatever hour suits you. Announce it at launch and again before it ends; the closing reminder often outperforms the opening one. Watch average order value alongside revenue on the [Dashboard](/analytics/dashboard), because a sale that lifts orders while cutting AOV may have lost you money. Judge it over the full week; a spike then a trough is normal. {% hint style="warning" %} **Discounting a subscription is not the same as discounting a one-off.** How far a sale reaches into a subscription depends on the **Discount Duration** you pick: **Apply once** discounts the signup only, while **Forever** and **Multiple subscription renewals** carry on into renewals. Choose it deliberately. {% endhint %} # Coupons Discount codes with limits, requirements and multi-month durations, for giveaways, targeting and win-backs. A coupon is a code a customer enters at checkout. Unlike a [sale](/marketing/sales) it is not automatic and not visible on the storefront, which makes it useful for giveaways, targeted offers and community rewards. *Dashboard → Marketing → Coupons. Needs `coupon_read`.* ## Creating a coupon Click **Create**. Six sections. ### Coupon Details Enter a **code**, or click **Generate** for a random one. Give it a **name** for your own reference; customers never see the name, only the code. Use memorable codes for public campaigns (`RAVEN10`) and generated codes for giveaways, where guessability is the risk. ### Coupon Lifetime Optional but recommended. Tick **enabled** and set the valid date range. ### Discount Details Choose **Percentage** or **Fixed**, and the value. Then set how long the discount applies to purchased packages: | Duration | Effect | | ---------------------------------- | --------------------------------------------------------------- | | **Apply once** | Discounts a single payment. | | **Forever** | Discounts every renewal, indefinitely. | | **Multiple subscription renewals** | Discounts a set number of subscription renewals, for example 6. | On an old coupon the third option reads **Multiple months** and counts months instead of renewals. That's a deprecated field kept for coupons that already used it; new coupons always count renewals. **Forever** and **Multiple subscription renewals** only apply to subscription products. They have no effect on one-time purchases. {% hint style="danger" %} **Forever means forever.** A Forever coupon on a monthly subscription discounts *every* renewal for as long as that customer stays subscribed. Issued carelessly, or leaked, it permanently reduces your recurring revenue with no expiry. Use **Multiple Subscription Renewals** for retention offers and reserve **Forever** for deliberate cases such as founding supporters or partners. {% endhint %} Two more options. **Apply Individually** applies the coupon to each product in the order rather than the order total. **Apply before sales** calculates the coupon discount before any active [sale](/marketing/sales), which changes the final price. Test with a real cart before publishing a code during a sale. ### Coupon Application Limit to specific **products** or **tags**, and optionally **bind it to a specific customer** so nobody else can use it. Leaving these empty applies the coupon to all products, usable by anyone with the code. Bind giveaway prizes to the winner, which makes the code worthless if shared. If they have never logged into your store, [create them first](/customers/creating-a-customer). ### Redeem Requirements Whether the coupon works on **one-time purchases**, **subscriptions** or both, and a **minimum order value**. ### Redeem Limits A **total usage limit** across the store, a **per-user limit**, or both. {% hint style="danger" %} **Always set limits on a public code.** With no total cap and no per-user cap, a code posted publicly can be used indefinitely by everyone who finds it, and game store codes spread to deal sites quickly. A store-wide limit of 50 with a per-user limit of 1 is a sane default for a community giveaway. {% endhint %}
The coupon creation form showing code, discount details and redeem limits.
Once created, the coupon's page lists every order it was applied to. ## What coupons are good for Giveaways, where a code costs you margin rather than cash. Win-backs, with a Multiple Subscription Renewals coupon aimed at lapsed subscribers. Partners and creators, each with their own bound, tracked code. And apologies after downtime, where a code repairs goodwill more cheaply than refunds. # Gift Cards Issue store credit with a balance customers can spend across purchases. A gift card carries a **balance** rather than a discount. The customer redeems it at checkout and spends it on whatever they like. *Dashboard → Marketing → Gift Cards. Needs `giftcard_read`.* ## Creating a gift card 1. Go to **Marketing → Gift Cards**. 2. Click **Create** in the top right. 3. Fill in: | Field | What it does | | ------------ | ----------------------------------- | | **Code** | Generate one, or enter it manually. | | **Name** | For your reference. | | **Duration** | Optional validity period. | | **Balance** | The amount of credit. | 4. Click **Create**.
The gift card creation form showing code, note, lifetime and balance.
Once the card exists, its page gains an **Orders using this gift card** section listing every order the card was applied to, which is how you track a partially-spent balance. It does not appear before creation. ## Gift cards versus coupons | | Gift Card | [Coupon](/marketing/coupons) | | ---------------------------- | ---------------------------------- | ----------------------------- | | What it gives | A spendable balance | A discount | | Spans purchases | Yes, until spent | No | | Customer chooses what to buy | Yes | Only within your restrictions | | Best for | Prizes, compensation, actual gifts | Targeted discounts, campaigns | For a giveaway, a gift card lets the winner pick what they want rather than pushing them at one product, and they often spend past the balance. ## Stacking Whether customers can combine several gift cards on one order is controlled by **Promo Code Stacking Behavior** in [Settings](/store-settings/store): | Setting | Effect | | --------------------------- | ----------------------------------------------- | | **Disable stacking** | One promo only. | | **Gift Card stacking only** | Multiple gift cards, but coupons never combine. | | **Enable stacking** | Everything combines. | **Gift Card stacking only** is the common choice: customers can use up several balances in one purchase while coupon discounts stay predictable. ## Issuing gift cards as a product A product can issue a gift card equal to its price on purchase, configured under **Deliverable Actions**. That is how you sell gift cards to your community so they can buy them for each other. See [Creating a Product](/products/creating-a-product). {% hint style="warning" %} **An outstanding gift card balance is money you owe.** Set a duration on promotional cards, or a balance can be redeemed years later, long after the campaign made sense. And don't hand out large balances casually: a 10% coupon costs you 10% of one sale, a $50 gift card costs you $50. {% endhint %} # Affiliate Links Pay creators and community members a commission for sales they refer, tracked by code or URL. Affiliate links let you partner with creators, influencers and community members who promote your store in exchange for a commission. Purchases are tracked by referral URL, such as `store.example.com/?aff=example`, or by a code entered at checkout. *Dashboard → Marketing → Affiliate Links. Needs `affiliate_link_read` and the **Pro** plan or above. See* [*Billing*](/payments-and-payouts/billing)*.* PayNow takes no additional cut of affiliate sales. You get built-in analytics, custom commissions per affiliate, optional discounts tied to the affiliate code, and direct payouts: commissions are credited to the affiliate's PayNow payout account. Your affiliates do not need a store of their own. They register for PayNow, choose **Setup Payouts** at first login, and receive settlements without ever creating one. See [Setting Up Your Payout Account](/getting-started/payout-account). ## Setting one up
The affiliate link creation form showing code, commission, discount and URL link details.
### 1. General Details | Field | What it does | | ------------------ | ------------------------------------------------------------------- | | **Affiliate Code** | The unique code, used at checkout or in the referral URL. | | **Payout ID** | The affiliate's PayNow payout identifier, where commission is paid. | The affiliate provides their own Payout ID. Get it from them rather than guessing. ### 2. Lifetime & Renewal | Field | What it does | | ------------------------------------ | --------------------------------------------------------------------- | | **Enabled** | Activates the link. | | **Credit for Subscription Renewals** | Whether commission applies to recurring payments, not just the first. | {% hint style="warning" %} **Credit for Subscription Renewals is the expensive setting.** Left on, the affiliate earns on every renewal for as long as that customer stays subscribed, potentially for years, off a single referral. That can be right for a creator driving high-quality signups and badly wrong as a blanket default. Decide deliberately, and tell your affiliates which model they are on before they start promoting. {% endhint %} ### 3. Commission Details **Commission Type** is percentage or fixed, and **Commission Amount** sets the figure per sale. **A percentage commission is capped at 30%**; the form rejects anything higher. {% hint style="warning" %} **The percentage is a split of the whole transaction, tax and fees included.** It is not calculated on what you take home. A customer pays **$20.00**. A 10% affiliate earns **$2.00**, taken off the top. Tax, the gateway fee and the platform fee then come out of your remaining $18.00, not out of the affiliate's share. Work your rates out from that. A 25% commission on a low-margin product can cost you more than the sale earns once tax and fees land on your side of the split. {% endhint %} Check [Transactions](/payments-and-payouts/transactions) to see what a given sale actually nets you. If you credit affiliates for renewals, **Commission Steps** lets you set a different rate for each successive renewal, tapering a 20% first-payment commission down to 5% by the fourth, for example. **Repeat last step forever** applies the final step to every renewal after it. Without that, renewals past the last step pay nothing. ### 4. Discount Options Optionally give customers a discount for using the affiliate's code. It is what makes the code worth sharing: the audience gets something, not just the creator. ### 5. Tracking Settings | Field | What it does | | ------------------- | ------------------------------------------------------- | | **Referrer Type** | Whether the **first** or **last** referrer gets credit. | | **Tracking Length** | How long the tracking cookie stays valid, e.g. 7 days. | Referrer type decides who gets paid when several affiliates touch one customer. **Last** rewards whoever closed the sale; **first** rewards discovery, which suits programmes built around creators introducing new players. PayNow's own default is **First Referer**, and a new link starts at a 7-day tracking window; the field accepts 1 to 365 days. ## Running a programme Start with a small number of affiliates and a modest commission, because raising it later is easy and cutting it is not. Give each affiliate their own code, or performance is unattributable. Check the numbers after a month, since an affiliate whose referrals all refund or charge back is costing you money. And be explicit about renewals in whatever you agree. # Upselling Offer additional products at checkout to raise order value without adding friction. Upselling suggests extra products or upgrades while the customer is already checking out. *Dashboard → Marketing → Upselling (store-wide), or a product's edit page (per-product). Needs `upsell_read`.* Available on every plan, Free and up. Works on both the standard checkout page and the PayNow\.js iframe embed. ## Enable Upselling Toggle **Enable Upselling** at the top of the Upselling page. When off, nothing below takes effect. ## Checkout Style How upsells are presented. Each option has a **View Image** link so you can preview the layout first. | Style | Where it appears | | ------------------------------- | ----------------------------------------------------------------------------- | | **Inline** | Below the checkout details, inside the main flow. | | **Inline & Pre-Payment Dialog** | Inline **and** as a dialog just before payment is confirmed, a second chance. | | **Dedicated Step** | A standalone step between details and payment. | **Inline** is what a store gets if the style has never been set. Of the three, only **Inline & Pre-Payment Dialog** puts something in front of the customer after they've decided to pay, so compare your checkout numbers before and after if you switch to it. ## Automatically Recommend Products Turn on **Enable Auto Recommendations** and PayNow selects upsells from your store's order history. Suggestions improve as you sell more, so on a new store they will be weak: start with store-wide recommendations you choose yourself and switch auto on once you have real volume. You can attach a discount. **Discount Type** is None, Fixed Amount or Percentage, and **Discount Amount** is the value applied to the upsell. A small discount lifts take-up without much margin impact. ## Store-Wide Recommendations Specific products offered as upsells across the whole store. Turn on **Enable Store-Wide Recommendations**, then **Add Store-Wide Recommendation**. | Field | What it does | | --------------------------------------- | ---------------------------------------------------------------------------- | | **Recommend Product** | The product to offer. | | **As an** | How it is presented. | | **Discount Type** | None, Fixed Amount, or Percentage. | | **Discount Amount** | The value applied. | | **Min. Recommended Prod Qty** | Minimum recommended quantity of the upsell product. | | **Offer Quantity** | Quantity offered to the customer. | | **Prefer recommending as subscription** | Offer as a subscription rather than one-time, where the product supports it. | Add more by clicking the button again; remove one with the red X. Turn on **Prefer recommending as subscription** where you can: converting a one-time buyer into a recurring one is worth more than the single sale. ## Per-Product Recommendations Set on a product's own edit page. Scroll to **Upselling**, toggle **Enable Upselling**, then **Add Recommendation**. Fields match store-wide, plus **Min. Product Qty**: how many of *that* product must be in the cart before the upsell shows. Per-product recommendations take priority. When a customer buys a product with its own upsells configured, those are shown instead of the store-wide list, not in addition to it.
The Upselling page showing the enable toggle, checkout style options and store-wide recommendations.
## Save your changes Click **Save Settings** at the bottom of each page, including the per-product page. Nothing takes effect until saved. ## What to offer Good upsells are cheap relative to the cart and obviously complementary. | Customer is buying | Good upsell | Poor upsell | | ------------------ | ---------------------------- | -------------------------- | | A rank | A currency pack, a cosmetic | A different rank | | A currency pack | A larger pack, a starter kit | A rank costing 5× the cart | | A one-time kit | The subscription version | Something unrelated | Track the effect on **average order value** on the [Dashboard](/analytics/dashboard). That is the number upselling exists to move. # Abandoned Checkouts Automatically email a discount coupon to customers who left without completing their purchase. When a customer starts a checkout and does not finish, PayNow can email them a discount coupon to bring them back. *Dashboard → Marketing → Abandoned Checkouts. Needs `abandoned_checkout_read`. Available on every plan including Free.* Customers must have accepted email marketing consent during a previous checkout session to be eligible, so recovery only works for people who have checked out with you before. ## Enabling it 1. Go to **Marketing → Abandoned Checkouts**. 2. Toggle **"Send automated emails with discount coupons to recover abandoned checkouts"**. PayNow then monitors for abandoned checkouts and attempts recovery with a coupon built from your configuration. ## Run Criteria When a recovery email should fire. | Setting | What it does | | ----------------------- | --------------------------------------------------------------- | | **Email Delay** | How long to wait after abandonment before sending, e.g. 1 hour. | | **Minimum Order Value** | Only trigger if the cart total is at least this. | | **Maximum Order Value** | Only trigger if the cart total is below this. | Too soon reads as surveillance; too late and they have forgotten or bought elsewhere. An hour is a sensible starting point. A minimum order value stops you discounting $2 carts, where the coupon costs more than the sale is worth. **Per user restrictions** cap max coupons per customer in a period, e.g. 1 every 1 day. **Global restrictions** cap total coupon sends in a period, e.g. 10 every 1 day. {% hint style="danger" %} **Set both restrictions before enabling this.** Without a per-user cap, someone can discover that abandoning a cart produces a discount code and never pay full price again. Without a global cap, a traffic spike or a broken checkout can generate a flood of coupons in one day, each one a real discount you have to honour. {% endhint %} ## Coupon Configuration | Setting | What it does | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Discount Type** | Percentage or Fixed amount. | | **Discount Amount** | The discount, e.g. 10%. | | **Recurring Discount Behaviour** | For subscription products: **Apply to first payment only**, **Apply to specified renewals of recurring payments**, or **Apply to all re-occuring payments**. | | **Coupon Expiry** | How long the coupon stays valid, e.g. 1 day. | | **Minimum Order Value** | Only apply if the new order meets this. | Redemption rules control whether the coupon works on one-time and subscription purchases, and and **Apply Discount Before Sales**, which changes the order the two discounts are calculated in. Work out what the combined discount costs before you turn it on. The older PayNow docs call this same setting "Apply even during other sales". Keep the expiry short. Urgency is what converts, and one day is typical. {% hint style="danger" %} **Recurring Discount Behaviour set to "all payments" discounts every future renewal**, for a customer who merely hesitated once. That is a permanent cut to your recurring revenue in exchange for one recovered signup. **First payment only** is almost always right. {% endhint %}
The Abandoned Checkouts page showing run criteria, restrictions and coupon configuration.
## Filtering **Product & Tag Restrictions** limit recovery discounts to specific products or [tags](/your-webstore/tags). **Coupon Usage Limits** set how many times a customer can use the code. ## Notes and limits Emails are automatic and not yet customisable. Your **Support Email** from [Settings](/store-settings/store) appears in them, so make sure it is one you monitor. ## Abandonment as a diagnostic A sudden jump in abandonment usually means something broke, not that your pricing changed. Check whether you changed [checkout branding](/your-webstore/branding), changed your [upsell style](/marketing/upselling), whether [payment methods](/your-webstore/webstore) are available in your customers' regions, and whether a price change landed recently. # Purchase Follow-Ups Email a discount coupon to customers after a successful purchase to bring them back for a second one. Where [Abandoned Checkouts](/marketing/abandoned-checkouts) chases people who did not buy, follow-ups target people who did, sending a coupon some time after a completed purchase to encourage the next one. *Dashboard → Marketing → Purchase Follow-Ups. Needs `purchase_follow_up_read`. Available on every plan including Free.* Customers must have accepted marketing consent during any previous checkout, either a completed order or a previous abandoned checkout where consent was given. ## Enabling it Go to **Marketing → Purchase Follow-Ups** and toggle **"Send automated emails with discount coupons to follow-up successful purchases"**. ## Run Criteria Which orders qualify. | Setting | What it does | | ----------------------- | ------------------------------------------- | | **Email Delay** | How long after purchase to wait, e.g. `7d`. | | **Minimum Order Value** | Only trigger at or above this total. | | **Maximum Order Value** | Optionally skip orders above this total. | The delay is the strategy. Too short and you are discounting a customer who was about to buy again anyway. Long enough that they have used what they bought, and the coupon arrives as a prompt rather than a price cut. Seven days is a reasonable default; if you sell monthly ranks, consider timing it near the end of the period instead. Set a maximum order value as well. Your highest-spending customers do not need a discount to buy again, so capping it points follow-ups at the middle of your customer base. ### Per user restrictions | Setting | Example | | ---------------------------- | ------------------------------------------------- | | **Max Coupons Per Customer** | 1 | | **Time Period** | `7d`, so at most one coupon every 7 days per user | ### Global restrictions | Setting | Example | | ---------------------- | ----------------------------------------- | | **Total Coupon Sends** | 100 | | **Time Period** | `28d`, so at most 100 sends every 28 days | ## Coupon Configuration | Setting | What it does | | -------------------------------- | ---------------------------------------------- | | **Discount Type** | Percentage or fixed. | | **Discount Amount** | e.g. `10%` or `$5`. | | **Recurring Discount Behaviour** | First payment only, or all recurring payments. | | **Coupon Expiry** | e.g. `1d`. | | **Minimum Order Value** | Optional threshold to use the coupon. | Purchase conditions enable or disable **One-Time Purchases** and **Subscription Purchases**, and **Apply Discount Before Sales** decides whether the coupon applies before active sales. {% hint style="danger" %} **"All recurring payments" permanently discounts every renewal** for that customer, as with abandoned checkouts. Use **first payment only** unless you are deliberately running a long-term loyalty discount. {% endhint %}
The Purchase Follow-Ups page showing run criteria, restrictions and coupon configuration.
## Filtering **Product & Tag Restrictions** limit follow-ups to specific products or [tags](/your-webstore/tags), and **Coupon Usage Limits** set how many times a customer can use the code. Point follow-ups at products the customer did not just buy. A coupon for something they already own converts nobody: send a currency coupon to someone who bought a rank, not another rank. Your **Support Email** from [Settings](/store-settings/store) appears in these emails. ## Follow-ups versus upselling Both grow order value, at different moments. | | [Upselling](/marketing/upselling) | Purchase Follow-Ups | | --------- | --------------------------------- | ----------------------- | | When | During checkout | Days after purchase | | Costs you | Margin on the upsell | Margin on a future sale | Try upselling first. It is free to attempt, and costs you a discount only if it works. # Game Servers Connect your game server so PayNow can deliver purchases automatically. Linking a game server turns a payment into an item in your player's hands. Without one, PayNow can take the money but has nowhere to send the goods. *Dashboard → Integrations → Game Servers. Needs `gameserver_read`.* ## Connecting a server 1. Go to **Integrations → Game Servers**. 2. Click **Add Game Server**. 3. Enter the server's **name**, and tick the box for executing commands if applicable. 4. Select the **products** to associate with this server. 5. **Download the plugin** for your game. 6. **Install the plugin** on your server and run the prompted command in the server console. The server then appears in your Game Servers list. Click it for details, or to reset the token and re-run the command. Step 6 is the one that gets skipped. The plugin alone isn't enough; the server has to run the registration command so PayNow knows which machine belongs to which entry. A server stuck on **Not Linked** is almost always this.
The Game Servers page showing a linked server that is Online, an unlinked one, and the Create button.
## Naming servers Name them the way your players talk about them: `Survival`, `Creative`, `Main EU`. You'll pick these from a dropdown on every product you build, and `Server 1` / `Server 2` guarantees a wrong selection eventually. ## Associating products A product delivers only to the servers selected on it. Set that from the game server by choosing its products, or from the [product](/products/creating-a-product) by choosing its game servers. {% hint style="danger" %} **On a multi-server store, check every product's server selection.** A product pointed at the wrong server sells fine and delivers where the customer isn't playing. They'll assume they were scammed, and they'll be partly right. If your servers have different catalogues, let customers choose at checkout instead. See `available_gameservers` in [Editing Template Files](/your-webstore/editing-template-files). {% endhint %} ## The token Each server has a token proving its identity to PayNow. Reset it from the server's detail page if it may have leaked, for example into a console screenshot posted in Discord. Resetting invalidates the old token, so you'll re-run the console command. Treat it like a password: anyone holding it can impersonate your server. ## Testing the connection A status of **Online** doesn't prove delivery works. Before going live: 1. Make a test purchase. 2. Watch the server console. The command should run within seconds. 3. Check the [order timeline](/orders-and-subscriptions/orders) to confirm execution was recorded. 4. Confirm the perk actually applied in game. Do all four. Each rules out a different failure. ## When commands do not run Three messages come up often enough to name. | What you see | What it means | | ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `failed to handle pending commands`, request timeout | The server or its host had a network problem and the request did not reach PayNow. The plugin keeps retrying, so this clears itself. | | Nothing works after reinstalling or moving the server | Run the link command again, then reload the plugin. Restart the server if it still shows stale. | | `No changes to apply` when relinking | The link command found nothing to change. Run `paynow link` again, then reload the plugin, then restart the server if it persists. | | Nothing at all in the console | Check the [order timeline](/orders-and-subscriptions/orders) first. If it shows the command executed, the problem is on the game side: the plugin, permissions, or the player being offline. | A command that runs twice is worth reporting with your plugin version and platform. It should not be possible, so it is a bug rather than a setting. The plugin only makes **outgoing** requests. There is no inbound connection, so there is never a port to forward, and a firewall rule is almost never the fix. A server that persistently cannot reach PayNow has a network problem at the host. ### FiveM FiveM's own platform rules have required monetisation to run through their approved provider, and servers using anything else have been warned of bans. That is FiveM's policy, not PayNow's. Check FiveM's current terms before building your store on it. # Commands & Placeholders How commands deliver a purchase to your game server, and every placeholder you can put in one. A command is the line your game server runs when something happens to an order. It is how a purchase becomes an actual rank, kit or item. A product with no command takes the customer's money and delivers nothing. *Set per product under **Deliverable Actions → Commands**, or for every product at once under* [*Global Commands*](/integrations-and-commands/global-commands)*.* ## How a command reaches your server 1. A customer buys something. 2. PayNow works out which commands apply: the product's own, plus any global commands for that stage. 3. PayNow substitutes the placeholders with real values from the order. 4. The command is sent to your linked [game server](/integrations-and-commands/game-servers), which runs it as console would. Step 4 is the part that fails. If the server is not connected, commands queue rather than disappear, and run once it reconnects. ## Writing one A command is your server's own console command, with placeholders where the player-specific parts go. You do not prefix it with a slash unless your server expects one from console. {% tabs %} {% tab title="Minecraft" %} Grant a LuckPerms group to whoever the purchase is for: ``` lp user {customer.minecraft.uuid} parent add vip ``` Use the **UUID**, not the name. Names change; UUIDs don't. A player who changes their username after buying still keeps what they paid for. Give an item and tell them it arrived: ``` give {customer.minecraft.name} diamond_pickaxe 1 tell {customer.minecraft.name} Thanks for buying {product.name}! ``` {% endtab %} {% tab title="Rust / Steam" %} Add the buyer to an Oxide group: ``` oxide.usergroup add {customer.steam.id} vip ``` Grant a permission directly: ``` oxide.grant user {customer.steam.id} kits.vip ``` Steam IDs are stable, so there is no equivalent of the Minecraft name-change problem. {% endtab %} {% endtabs %} The exact syntax comes from your server and its plugins, not from PayNow. If the command works when you type it into your server console, it will work here. ### One command per line Each command goes in its own row with its own stage. Don't chain several into one line and hope the server splits them. ## Stages The stage decides when the command runs. | Stage | Runs when | | -------------------- | ----------------------------------------------------------------------- | | **On Purchase** | The order completes. | | **On Renew** | A subscription renews. | | **On Expire** | A subscription or timed product expires, **or you revoke it manually**. | | **On Refund** | You refund the order. | | **On Chargeback** | The customer disputes the charge with their bank. | | **On Trial Started** | A [trial](/orders-and-subscriptions/trials) begins. | | **On Trial Expired** | A trial ends without converting. | {% hint style="danger" %} **On Purchase does not fire when a trial starts, and it does not fire on renewal.** A product with only an On Purchase command delivers nothing during a trial, and a subscription that grants a temporary perk will not re-grant it when the customer renews. Pair every grant with its matching removal. A rank given On Purchase and never removed On Refund or On Chargeback is a rank you gave away for free. {% endhint %} ### Revoking runs On Expire There is no separate revoke stage. When you revoke a product from a customer's inventory, PayNow runs the **On Expire** commands, the same ones an actual expiry would run. Put your removal command on On Expire and it covers both. Put it only on On Refund and a revoked customer keeps whatever you gave them, because a revoke is not a refund. ## Execute when online A checkbox on each command. The dashboard describes it as: *if the player is offline, the command executes when the player joins the server.* Turn it on for anything that needs a connected player: a chat message, a spawned item, a temporary effect. Leave it off for permission and rank changes, which most plugins apply fine against an offline player. It matters most on removals. A revoke that waits for the player to come back is a revoke that may never happen, and the customer who charged back keeps their rank indefinitely. ## Game servers to execute on Also per command. Left empty, the command runs on *all game servers selected on the product*. Select one or more and that choice **overrides** the product's servers. On a single-server store, leave it empty. On a multi-server store, leaving it empty is usually still what you want, because the product already knows which server it was bought for. ## Placeholders You don't have to memorise these. The command editor has an **Available variables** link that opens the whole list, and each entry copies to your clipboard when you click it.
The Available command variables tooltip listing every placeholder with a copy icon and a description, above the Available variables link that opens it.

Click any placeholder in the tooltip to copy it.

The full set: ### Who the purchase is for `{customer.*}` is the **recipient**. This is the one you want in almost every command. | Placeholder | Value | | ----------------------------- | -------------------------- | | `{customer.id}` | Recipient's PayNow ID | | `{customer.name}` | Recipient's name | | `{customer.steam.id}` | Recipient's Steam ID | | `{customer.steam.name}` | Recipient's Steam name | | `{customer.steam.avatar}` | Recipient's Steam avatar | | `{customer.minecraft.uuid}` | Recipient's Minecraft UUID | | `{customer.minecraft.name}` | Recipient's Minecraft name | | `{customer.minecraft.avatar}` | Recipient's Minecraft skin | ### Who paid `{order.customer.*}` is the **buyer**. On an ordinary purchase these are the same person as above. On a gift they are not. | Placeholder | Value | | ----------------------------------- | --------------------------------------- | | `{order.customer.id}` | Buyer's PayNow ID | | `{order.customer.name}` | Buyer's name | | `{order.customer.steam.id}` | Buyer's Steam ID | | `{order.customer.steam.name}` | Buyer's Steam name | | `{order.customer.steam.avatar}` | Buyer's Steam avatar | | `{order.customer.minecraft.uuid}` | Buyer's Minecraft UUID | | `{order.customer.minecraft.name}` | Buyer's Minecraft name | | `{order.customer.minecraft.avatar}` | Buyer's Minecraft avatar | | `{order.gifted_by_customer_id}` | ID of the customer who gifted this item | {% hint style="warning" %} **Using `{order.customer.*}` to deliver a product breaks gifting.** Someone buys a rank for a friend, and the rank lands on the person who paid. Reach for `{order.customer.*}` only when you genuinely mean the payer, such as thanking them in chat. {% endhint %} ### Product | Placeholder | Value | | ---------------------- | ----------------------------------------------------------------- | | `{product.id}` | ID of this product | | `{product.name}` | Name of this product | | `{product.slug}` | Slug of this product | | `{product.version_id}` | ID of the product version | | `{product.price}` | Base price **in the lowest denomination**, so $14.99 gives `1499` | ### Order | Placeholder | Value | | ------------------- | -------------------------------- | | `{order.id}` | ID of the order | | `{order.pretty_id}` | The short order ID customers see | | `{order.line_id}` | ID of this line of the order | | `{checkout.id}` | ID of the checkout session | | `{store.id}` | ID of your store | | `{order.currency}` | Currency of the order | ### Amounts These are **per order line**, not per order. A customer who buys three things gets three separate command runs, each with its own line amounts. | Placeholder | Value | | ------------------------------------ | ---------------------------------- | | `{order.line.subtotal_amount}` | Subtotal for this line | | `{order.line.discount_amount}` | Discount applied to this line | | `{order.line.giftcard_usage_amount}` | Gift card amount used on this line | | `{order.line.tax_amount}` | Tax on this line | | `{order.line.total_amount}` | Total for this line | ## Custom variables in commands A [custom variable](/integrations-and-commands/custom-variables) asks the customer something at checkout and drops their answer into the command. Reference it by its **Identifier**, in braces like any other placeholder. A variable with the identifier `kit` becomes `{kit}`: ``` givekit {customer.minecraft.name} {kit} ``` The customer picks their kit at checkout, and the command that runs carries their choice. ## Checking a command actually ran Open the order and read its [timeline](/orders-and-subscriptions/orders). It records command execution alongside creation and completion, which splits any "I paid and got nothing" report in two: * **No execution logged.** A PayNow-side delivery problem. Check the command is attached to the right stage, and that the [game server](/integrations-and-commands/game-servers) is connected. * **Execution logged.** A game-side problem. Check the plugin, the permission node, and whether the player was online if you ticked **Execute when online**. If the command was wrong and you have since fixed it, [resend it](/integrations-and-commands/resending-commands) rather than asking the customer to buy again. # Global Commands Commands that run for every product on a given event — purchase, expiry, renewal, refund or chargeback. A global command runs on an event regardless of which product was involved. Use them for things that should always happen: announcing a sale in chat, logging to an external system, revoking access when money comes back out. *Dashboard → Store → Global Commands. Needs `global_command_read`.* ## Creating one 1. Go to **Store → Global Commands**. 2. Click **Create** in the top right. 3. Configure the fields below. ### Stage When the command fires. | Stage | Fires when | | ----------------- | --------------------------------------------------- | | **On Purchase** | Immediately after a product is purchased. | | **On Expire** | When a product expires, **or is revoked manually**. | | **On Renew** | On a recurring subscription renewal. | | **On Refund** | When an order is refunded. | | **On Chargeback** | When a chargeback occurs. | {% hint style="danger" %} **Set a command on On Refund and On Chargeback.** Without them, a customer who refunds, or disputes the charge with their bank, keeps everything they were given. You're out the money *and* the goods. At minimum, remove the purchased permissions or rank on both stages. {% endhint %} ### Command The command to execute. It is sent to the game server or integration depending on your setup. The same 33 placeholders work here as on a product command. See [Commands & Placeholders](/integrations-and-commands/commands). ### Execute when online Optional. When enabled, the command only runs while the customer is online. Left unchecked, it queues and runs when possible. Enable it for commands that only make sense against a connected player, such as a chat message or a session effect. Leave it off for permission and rank changes. A revoke that waits for the player to come back online is a revoke that may never happen. ### Game Servers to Execute On | Setting | Behaviour | | ------------------------ | ----------------------------------------------------- | | **Left empty** | Applies to **all game servers selected per product**. | | **One or more selected** | **Overrides** the product-level server setting. | That override catches people out on multi-server stores: the command runs on *those* servers no matter which server the product was bought for. Leave it empty unless you want that. ## Managing global commands The table shows the **Stage** it triggers on, the **Content** of the command, and **Last Updated**. Edit or delete from the contextual options in the table.
The Global Commands table showing the stage and content of each command.
## Global versus product commands | Use a **global** command when | Use a **product** command when | | -------------------------------- | ------------------------------ | | It applies to every purchase | It delivers a specific item | | Announcing sales in chat | Granting a specific rank | | Logging to an external system | Giving a specific kit | | Revoking on refund or chargeback | Anything product-specific | Both run. A global On Purchase command fires *in addition to* the product's own commands, not instead of them, on the product's [game servers](/integrations-and-commands/game-servers) unless you override that above. # Custom Variables Collect input from customers at checkout, such as a colour or a name, and use it in commands. Custom variables ask the customer a question at checkout and feed the answer into your commands. One product can then cover what would otherwise be a dozen near-identical ones. *Dashboard → Store → Custom Variables. Needs `custom_variable_read`.* ## Creating one 1. Go to **Store → Custom Variables**. 2. Click **Create**. | Field | What it does | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Name** | Shown to the customer. | | **Identifier** | How you reference it in commands, as `{identifier}`. | | **Description** | Optional. Appears under the input on the product page. | | **Type** | Dropdown (a fixed set of options, such as server region or item colour), Text (freeform, such as a username or name tag), or Number (levels, amounts). | **Text** and **Number** support **regex validation**. {% hint style="warning" %} **Validate every text input that reaches a command.** A freeform field is customer-supplied text going straight into your server console. Without a regex, someone can enter spaces, quotes or command syntax and change what actually executes. For a name tag, `^[A-Za-z0-9_]{1,16}$` is a reasonable start: letters, digits and underscores only, capped at 16 characters. {% endhint %} ## Using them in commands Given a `{kit}` dropdown of bronze, silver and gold, a `{name}` text field and a `{slots}` number field: ```bash oxide.usergroup add {customer.steam.id} {kit} say "{customer.name} just purchased the {kit} package!" o.grant user {customer.steam.id} backpacks.size.{slots} ``` If the customer picks **gold**, **Lord** and **6**, the executed commands are: ```bash oxide.usergroup add 7656119XXXXXXXXXXX gold say "Lord just purchased the gold package!" o.grant user 7656119XXXXXXXXXXX backpacks.size.6 ``` Attach variables to a product from its [edit page](/products/creating-a-product). They mix freely with the built-in placeholders; see [Commands & Placeholders](/integrations-and-commands/commands). ## Dropdown pricing Dropdown options can carry an extra charge. | Field | What it does | | ------------------- | ------------------------------------------- | | **Name / Value** | Shown to the customer and used in commands. | | **Pricing Type** | Fixed or Percentage. | | **Additional Cost** | Extra charged for that option. | This replaces whole tiers of products. Instead of Bronze, Silver and Gold Kit as three products with three sets of commands, sell one Kit product with a `{kit}` dropdown priced at +$0 / +$5 / +$12. One product to maintain, and the customer sees the upgrade options while they're already buying. See also [Upselling](/marketing/upselling). ## Blank variables Variables are optional. If a customer leaves one blank, the placeholder resolves to nothing, so `o.grant user {id} backpacks.size.{slots}` with `{slots}` empty produces a malformed command. Set a sensible default, or validate that it can't be empty. # Resending Commands Re-run a failed delivery command for a customer's purchase. When a command fails, you can re-run it for that one customer without refunding or re-granting the package. Resend after a server restart killed the original command, after a temporary issue stopped a customer receiving their purchase, or whenever the execution status shows **failed** or **pending**. ## How to resend 1. Go to **Content → Customers** and select the customer. 2. Open the **Inventory** tab. 3. Find the purchased package. 4. Click the **Info button ( ℹ️ )** next to it. 5. The **Command UI** opens, showing the **executed command**, the **game server** it ran on, and the **execution status**: Success, Failed or Pending. 6. Click **Resend Command**. 7. **Select the game server** to re-execute on. 8. Confirm. You can only resend for packages that are still active. Expired packages no longer have access to their deliverables, and the option is unavailable. {% hint style="warning" %} **Read the Command UI before you resend.** It tells you whether the command actually ran, on which server, and whether it succeeded. Resending one that already succeeded gives the customer the item twice, and you don't get it back. {% endhint %} ## If the command fails again Check, in order: 1. The **game server is online** and properly connected. See [Game Servers](/integrations-and-commands/game-servers). 2. The **player exists**, and is **online** if the command requires it. 3. The **command syntax** is correct for the game. If it keeps failing, check your server logs and contact [PayNow Support](https://discord.gg/paynow). ## You can't edit a command before resending Resend re-runs the **exact command** that was originally executed. If you need a different one, either run the corrected command manually on your game server, or edit the package's commands and **re-grant the package** to the customer, which triggers the updated version. Take the second route when the command was wrong for everyone rather than for this one customer. Fix the product first, or you'll be resending failures one at a time all week. For a group of affected customers, see [Bulk Assigning Products](/products/bulk-assigning-products). ## Preventing this Test every product before selling it: buy it yourself and watch the command run. Use the customer placeholder rather than a hard-coded name. After any server incident, check the [order timeline](/orders-and-subscriptions/orders) to see what failed while you were down. Queued commands catch up when a server returns, so a brief outage usually resolves itself. Check before you resend. # Discord Servers Link your Discord server so purchases can grant roles, kick, ban or issue invites. Linking Discord lets purchases trigger actions there. Most stores use it to assign a role, so a supporter's rank shows in the community as well as in game. *Dashboard → Integrations → Discord Servers. Needs `discord_server_read`.* ## Linking a server ### 1. Create the entry 1. Go to **Integrations → Discord Servers**. 2. Click **Add Discord Server**. 3. A window appears with instructions to add the PayNow bot and a registration command. The entry stays at status **Not linked** until registration completes. ### 2. Add the bot and register 1. Click the entry to open the **Discord Server details** window. 2. Click **Add Bot** to invite the official PayNow Discord bot. 3. Complete Discord's authorisation flow. 4. **Position the bot's role above the roles you want it to manage** in your server's role hierarchy. 5. Copy the registration command, for example `/pnregister YOUR_SERVER_KEY`. 6. Run it in any text channel on your Discord server. Once registered, the entry shows your Discord server name and ID.
The Discord Servers page showing one linked server and one awaiting registration.
{% hint style="danger" %} **Step 4 causes more failures here than everything else combined.** Discord won't let a bot manage roles positioned above its own, so the role is never applied. The purchase itself still completes; the failed Discord action is recorded on the order's timeline. In **Server Settings → Roles**, drag the PayNow bot's role above every role it needs to grant. Do this before your first sale, not after the first complaint. {% endhint %} ## What Discord actions can do Once linked, a product can assign a role, kick a user, ban a user, or generate an invite link. Configure these under **Deliverable Actions** on the [product](/products/creating-a-product). [Discord Linking](/integrations-and-commands/discord-linking) walks through the purchase-to-role setup. Each action is pointed at one of your linked Discord servers, chosen from a dropdown on the action itself. A server that is still **Not linked** does not appear in that dropdown. ## Re-linking and removing | State | What clicking the entry does | | -------------- | ----------------------------------------------------- | | **Not linked** | Opens the linking UI so you can repeat registration. | | **Linked** | Opens a details window with **Delete** and **Close**. | **Delete** fully unlinks the Discord server from your PayNow account. If a server shows as *Not linked*, click it and run the registration command again. ## Customers who forget to link Discord Someone buys a Discord perk without linking their account, then asks why they have no role. Two fixes: * On the [order](/orders-and-subscriptions/orders), hover the Discord icon on the line item to copy the Discord account-linking link for that order, and send it to them. * On the customer's [inventory](/customers/managing-customers#inventory) item, use the **Discord button** to enter their Discord User ID directly. # Discord Linking Assign Discord roles automatically on purchase, and understand when roles are removed. Linking Discord lets purchases assign roles automatically, so a supporter's rank shows in your community as well as in game. This page covers the purchase-to-role flow. Before any of it works, the Discord server itself has to be linked: add the PayNow bot, put its role above the roles it will manage, and run `/pnregister ` in a channel. Those steps are in [Discord Servers](/integrations-and-commands/discord-servers). ## Assign roles in Deliverable Actions 1. Go to **Content → Products**. 2. Create or edit a product. 3. Scroll to **Deliverable Actions**. 4. Click **Add Action** → **Assign Discord Role**. 5. Choose your **Discord Game Server** from the dropdown. 6. Select the **role** to assign on purchase. 7. **Save.** Customers buying this product now receive the role automatically. ## When roles are removed On the product's Discord action, **Remove role access on** offers three triggers. A new action starts with **all three ticked**. | Trigger | Fires when | | -------------- | -------------------------------------------------- | | **Expiration** | The product expires **or you revoke it manually**. | | **Refund** | You refund the order. | | **Chargeback** | The customer disputes the charge with their bank. | **Revoking runs the expiry path**, so Expiration covers manual revocation too. There is no separate "on revoke" trigger to look for. {% hint style="warning" %} **Unticking one of these is how customers keep a role they no longer paid for.** They are on by default for a reason. Untick Chargeback and someone who disputes the charge keeps the role permanently. {% endhint %} ## FAQ **Can I link multiple Discord servers?** Yes. Create multiple Discord server integrations, just as you would game servers. **What permissions does the bot need?** **Manage Roles** to assign roles, and **Read Messages** to process commands. Both are requested automatically when you invite the bot, so no manual adjustment is needed unless permissions are later changed in Discord. **What happens if a user leaves the server?** If they leave and rejoin, the bot **automatically reassigns their role**, as long as the package is still active and unexpired. It syncs their roles to the current state of their package. **Linking bounces back to checkout without linking.** Usually the customer's browser: an ad or privacy blocker interrupting the Discord redirect. Have them retry in a private window with extensions off. **A customer bought but has no role. What now?** They probably never linked their Discord. See [Customers who forget to link Discord](/integrations-and-commands/discord-servers#customers-who-forget-to-link-discord). # Delivery Methods How PayNow delivers what you sell, and how to set up delivery when you are not running a game server. Every product needs a route to the buyer. PayNow has two, and your store uses one of them: a connected **game server**, or a **delivery webhook**. *Dashboard → Settings. Store owner or `store_update`.* ## Which one your store uses Your store's **business type** decides it. | Business type | Delivery | | ------------- | --------------------------------------------------------------------------------- | | A game server | The PayNow plugin on your server runs the product's commands. | | Anything else | A delivery webhook. PayNow calls your endpoint and your system fulfils the order. | If you are selling software, downloads, a SaaS product or anything that is not a game server, set the business type to **SaaS** and configure a delivery webhook. A store set to the wrong type has no working route to the buyer, and orders complete without anything being delivered. You cannot skip this. PayNow has to know what to expect when an order completes, so a store with neither a connected server nor a delivery webhook cannot deliver. ## A delivery webhook is not a Discord webhook These are two different things with the same word, and mixing them up is the most common setup mistake here. * The webhooks on [Webhooks](/integrations-and-commands/webhooks) post **notifications** into a Discord channel so you can watch sales come in. They deliver nothing to the customer. * A **delivery webhook** is an endpoint on your own system. PayNow calls it when an order completes and your code grants the thing that was bought. A Discord webhook URL will not work as a delivery endpoint. ## Validate it before going live A delivery webhook has to be proven to work, and PayNow checks by requiring a real order through it rather than trusting the configuration. Make a genuine purchase that costs nothing: 1. Create a **coupon** or **gift card** that brings the total to zero, or price a test product at **0**. 2. Buy the product through your own storefront. 3. Confirm your endpoint received the call and delivered. That is also the fastest way to test a game-server store. See [Game Servers](/integrations-and-commands/game-servers#testing-the-connection). ## Minecraft: which integration to pick Three options, and the difference is how a player is identified. | Option | Identifies players by | Use when | | --------------------- | ------------------------------- | --------------------------------------- | | **Minecraft** | UUID | Your server is Java and online-mode. | | **Minecraft Geyser** | UUID, for both Java and Bedrock | Bedrock players connect through Geyser. | | **Minecraft offline** | Name only, no UUID validation | Your server runs offline-mode. | {% hint style="warning" %} **Offline mode identifies buyers by name alone.** Names can be taken by someone else, so a purchase can be delivered to the wrong person. Use UUID-based identification wherever your server allows it. {% endhint %} # Webhooks Send store events to Discord as embeds, or to your own systems as JSON. Webhooks push notifications about store events somewhere else: a Discord channel, or your own endpoint. Most stores post sales into Discord, which doubles as social proof. *Dashboard → Integrations → Webhooks. Needs `webhook_read`. Available on every plan including Free.* For **JSON webhooks**, payload schemas and delivery semantics are in the [developer docs](https://docs.paynow.gg/api/webhook-introduction). This page covers setup in the dashboard. These webhooks notify. They do not deliver anything to the customer. If your store is not running a game server, the endpoint that fulfils orders is a delivery webhook and it is set up separately. See [Delivery Methods](/integrations-and-commands/delivery-methods). ## Creating a Discord webhook ### 1. Create the webhook in Discord If you haven't made one before, follow Discord's [Intro to Webhooks](https://support.discord.com/hc/en-us/articles/228383668-Intro-to-Webhooks). You need the resulting webhook URL. ### 2. Add it to PayNow 1. Go to **Integrations → Webhooks**. 2. Click **Create** in the top right. 3. Choose the type, **Discord** or **JSON**. Pasting a Discord URL selects Discord automatically. 4. Paste the Discord webhook URL as the **endpoint URL**. ### 3. Subscribe to one event In **Subscribed To**, select a single event. Start with `Order Completed`. Use one webhook entry per event. Each event carries different variables, and one embed template can't render all of them. Separate entries also let you send refunds to a private staff channel while sales go to a public one. ### 4. Edit the embed Hovering **Discord Embed Template** lists the variables for that event, and [Discord Placeholders](/integrations-and-commands/discord-placeholders) covers all of them. Ready-made embeds are on [Steam Templates](/integrations-and-commands/steam-templates) and [Minecraft Templates](/integrations-and-commands/minecraft-templates). Press **Update** when it looks right. ### 5. Repeat for other events Repeat for Refunds, Chargebacks, Subscriptions and anything else you want to see, adjusting the variables each time.
The webhook creation form with Discord selected and the Order Completed event subscribed.
## Which channel should receive what | Event | Suggested destination | Why | | ------------------- | --------------------- | ---------------------------------------------------- | | `Order Completed` | Public channel | Visible sales are social proof and drive more sales. | | Refunds | Private staff channel | Not something to broadcast. | | Chargebacks | Private staff channel | Needs a staff response, not an audience. | | Subscription events | Staff channel | Useful for spotting churn early. | {% hint style="danger" %} **Think before posting orders publicly.** The embed can include customer names and purchase details. Some communities love a sales feed; others treat it as a privacy problem, especially where the purchase reveals something about the player. Include only the variables you'd be comfortable seeing about yourself. {% endhint %} Treat the webhook URL itself as a secret. Anyone holding it can post to that channel as your bot, so don't share it and mask it in screenshots. # API Behaviour Notes Behaviours of the Storefront and Management APIs that the endpoint reference does not spell out. The [API reference](https://docs.paynow.gg) documents every endpoint and schema. This page is the handful of behaviours around them that support gets asked about, collected in one place. ## Products must exist before checkout API checkouts sell **pre-defined products**: everything you offer through a checkout has to be created in the dashboard (or via the Management API) first, then referenced by `product_id` in the checkout's `lines`. Defining a product inline at checkout time is not part of the standard platform. If your volume is large enough that per-checkout products are genuinely necessary, that is an enterprise conversation with PayNow rather than an API flag. ## Mixing one-time and subscription lines A single checkout can contain both one-time products and subscription products. Older templates and integrations sometimes assume one type per checkout; that restriction no longer applies. ## Active delivery items only show enqueued deliveries The active delivery-items endpoint lists items with a **command attempt enqueued** — a delivery routed to a game server. A customer's product that has no command attempt attached will not appear there, even though the customer owns it. If you are reconciling ownership rather than deliveries, read the customer's inventory instead. ## Building PayNow into an existing storefront If you have integrated a checkout API before (Stripe Checkout is the closest comparison), the shape is familiar: create your products, create a checkout session with `lines`, redirect the customer to the returned `url`. The [Delivery Methods](/integrations-and-commands/delivery-methods) page covers what your store must have configured before any of it can deliver. # Discord Placeholders Every placeholder available in Discord webhook embeds, organised by what each event actually adds. Placeholders insert live data into your Discord embed. Which ones are available depends on the event the [webhook](/integrations-and-commands/webhooks) is subscribed to. A placeholder that doesn't exist for the event renders blank, which is the usual reason an embed looks half-empty. Check the event's section below before using a variable. *Dashboard → Integrations → Webhooks → (a webhook) → **Discord Embed Template**. Hovering that field shows the list for the current event.* There are eleven events but only seven distinct variable sets, because several events share identical lists. The two shared blocks are defined once below, and each event lists only what it adds. ## Block A: customer (every event) Available in **all eleven events**. ``` {store_id} {customer.id} {customer.steam.id} {customer.steam.name} {customer.steam.avatar_url} {customer.minecraft.id} {customer.minecraft.name} {customer.minecraft.avatar_url} {customer.profile.id} {customer.profile.platform} {customer.profile.name} {customer.profile.avatar_url} ``` Use `{customer.profile.*}` if you want one template that works everywhere. The `steam` and `minecraft` variants are blank on the wrong platform, but `profile` resolves to whichever identity the customer actually used, and `{customer.profile.platform}` tells you which. ## Block B: product object Available in **Delivery**, **Subscription** and **Discord Linked to Order** events. **Not** available in Order Completed, Refund Completed or Chargeback Created. ``` {product.id} {product.name} {product.store_id} {product.description} {product.version_id} {product.enabled} {product.image_url} {product.label} {product.slug} {product.price} {product.sort_order} {product.tag_names} {product.created_at} {product.gameserver_names} {product.updated_at} {product.single_game_server_only} {product.allow_one_time_purchase} {product.allow_subscription} {product.subscription_interval_value} {product.subscription_interval_scale} {product.remove_after_enabled} {product.remove_after_time_value} {product.remove_after_time_scale} ``` *** ## Delivery events **Delivery Item Added**, **Delivery Item Activated**, **Delivery Item Revoked** and **Delivery Item Used** all share exactly the same variables. **Block A + Block B**, plus: ``` {id} {order_id} {product_id} {checkout_id} {subscription_id} {execute_on_gameserver_id} {execute_on_gameserver.id} {execute_on_gameserver.name} {execute_on_gameserver.enabled} {added_at} {active_at} {expires_at} {removed_at} {revoked_at} {revoke_reason} ``` Because all four share one variable set, `{revoke_reason}` and `{revoked_at}` technically exist on *Delivery Item Added*. They'll simply be empty. Only use them on the Revoked event. ## Order Completed **Block A only**, no product object. Use `{product_names}` for a summary line. ``` {id} {checkout_id} {subscription_id} {created_at} {product_names} {product_tags} {product_gameservers} {currency} {tax_inclusive} {subtotal_amount} {discount_amount} {tax_amount} {total_amount} {billing_email} {billing_address_country} ``` ## Refund Completed **Block A**, plus: ``` {id} {order_id} {gateway} {currency} {amount} {tax_amount} {gateway_fee_amount} {platform_fee_amount} {store_net_amount} {store_refund_amount} {created_at} ``` ## Chargeback Created **Block A**, plus: ``` {id} {order_id} {gateway} {currency} {amount} {tax_amount} {gateway_fee_amount} {platform_fee_amount} {store_net_amount} {chargeback_at} ``` Chargeback Created is Refund Completed minus `{store_refund_amount}`, with `{chargeback_at}` in place of `{created_at}`. Copying a refund template across leaves one blank field. ## Subscription Activated and Subscription Renewed Identical variable sets. **Block A + Block B**, plus: ``` {id} {status} {customer_id} {checkout_id} {checkout_line_id} {billing_cycle_sequence} {billing_email} {billing_country} {customer_ip} {product_id} {product_version_id} {product_name} {product_image_url} {currency} {interval_value} {interval_scale} {subtotal_amount} {tax_amount} {discount_amount} {total_amount} {initial_subtotal_amount} {initial_tax_amount} {initial_discount_amount} {initial_total_amount} {initial_giftcard_usage_amount} {current_period_start} {current_period_end} {created_at} {active_at} ``` `{billing_cycle_sequence}` is how you tell a first payment from a renewal: `1` is the initial charge. The `initial_*` amounts are what they paid at signup, useful for spotting subscribers still on an old promotional price. ## Subscription Canceled Everything from Activated / Renewed, plus: ``` {canceled_at} {cancel_reason} ``` ## Discord Linked to Order **Block A + Block B**, plus: ``` {order_id} {product_id} {customer_id} {checkout_id} {checkout_line_id} {enqueued_at} {discord_user_id} {discord_user_name} {discord_user_avatar_hash} {order.id} {order.store_id} {order.customer} {order.checkout_id} {order.subscription_id} {order.coupon_id} {order.currency} {order.tax_inclusive} {order.tax_amount} {order.discount_amount} {order.subtotal_amount} {order.total_amount} {order.giftcard_usage_amount} {order.created_at} {order.completed_at} {order.billing_name} {order.billing_email} {order.billing_address_country} {order.customer_ip} {order.product_names} {order.status} ``` ## Think before you publish these {% hint style="danger" %} Several placeholders expose personal data: `{billing_email}`, `{order.billing_name}`, `{customer_ip}`, `{order.customer_ip}`, and the various country fields. **Don't put these in an embed posted to a public channel.** A public sales feed should carry the player name, the product and maybe the amount, nothing that identifies the person off the server. Send anything sensitive to a private staff channel instead. {% endhint %} Ready-made embeds using these variables are on [Steam Templates](/integrations-and-commands/steam-templates) and [Minecraft Templates](/integrations-and-commands/minecraft-templates). Full payload schemas are in the [webhook developer docs](https://docs.paynow.gg/api/webhook-introduction). # Steam Templates Ready-made Discord embed templates for Steam-based stores, ready to copy and paste. Copy-paste embed templates for Steam-based stores such as Rust. Paste one into **Discord Embed Template** on a [webhook](/integrations-and-commands/webhooks) subscribed to the matching event. Each template belongs to one event, so pasting an Order Completed template onto a webhook subscribed to refunds produces blank fields. Running Minecraft? Use [Minecraft Templates](/integrations-and-commands/minecraft-templates). The templates are otherwise identical but use `{customer.minecraft.*}` instead of `{customer.steam.*}`. Running both? Swap `{customer.steam.name}` / `{customer.steam.id}` for `{customer.profile.name}` / `{customer.profile.id}` and one template covers both platforms. See [Discord Placeholders](/integrations-and-commands/discord-placeholders). ## General ### Order Completed ``` An order has been completed. **Customer Info** **Player** ➜ {customer.steam.name} **SteamID** ➜ {customer.steam.id} **Customer ID** ➜ {customer.id} **Product Info** **Products** ➜ {product_names} **Server** ➜ {product_tags} **Subscription ID** ➜ {subscription_id} **Price** ➜ {total_amount} **Links** PayNow - [Click Here](https://dashboard.paynow.gg/customers/{customer.id}) ``` ### Refund Completed ``` A product has been refunded! **Customer Info** **Player** ➜ {customer.steam.name} **SteamID** ➜ {customer.steam.id} **Customer ID** ➜ {customer.id} **Order Information** **OrderID** ➜ {order_id} **Amount** ➜ {store_refund_amount} **Links** PayNow - [Click Here](https://dashboard.paynow.gg/customers/{customer.id}) ``` ### Chargeback Created ``` ⚠️ A chargeback has been created! **Customer Info** **Player** ➜ {customer.steam.name} **SteamID** ➜ {customer.steam.id} **Customer ID** ➜ {customer.id} **Order Information** **OrderID** ➜ {order_id} **Amount** ➜ {amount} **Gateway** ➜ {gateway} **Chargeback at** ➜ {chargeback_at} **Links** PayNow - [Click Here](https://dashboard.paynow.gg/customers/{customer.id}) ``` {% hint style="danger" %} **Send chargebacks to a private staff channel.** They need a staff response. Check whether the customer still holds active access, and consider a [ban](/customers/bans). They aren't something to broadcast publicly. {% endhint %} ## Delivery ### Delivery Item Added ``` A product has been added! **Customer Info** **Player** ➜ {customer.steam.name} **SteamID** ➜ {customer.steam.id} **Customer ID** ➜ {customer.id} **Product Info** **Product** ➜ {product.name} **Server** ➜ {product.label} **Product ID** ➜ {product_id} **Links** PayNow - [Click Here](https://dashboard.paynow.gg/customers/{customer.id}) ``` ### Delivery Item Activated ``` Commands for product have been processed! **Customer Info** **Customer ID** ➜ {customer.id} **Player** ➜ {customer.steam.name} **SteamID** ➜ {customer.steam.id} **Product Info** **Product** ➜ {product.name} **Product ID** ➜ {product_id} **Server** ➜ {product.label} **Activated at** ➜ {active_at} **Expires at** ➜ {expires_at} **Links** PayNow - [Click Here](https://dashboard.paynow.gg/customers/{customer.id}) ``` ### Delivery Item Used ``` A product has been used! **Customer Info** **Player** ➜ {customer.steam.name} **SteamID** ➜ {customer.steam.id} **Customer ID** ➜ {customer.id} **Product Info** **Product ID** ➜ {product_id} **Product** ➜ {product.name} **Server** ➜ {product.label} **Links** PayNow - [Click Here](https://dashboard.paynow.gg/customers/{customer.id}) ``` ### Delivery Item Revoked ``` A product has been revoked! **Customer Info** **Player** ➜ {customer.steam.name} **SteamID** ➜ {customer.steam.id} **Customer ID** ➜ {customer.id} **Product Info** **Product ID** ➜ {product_id} **Product** ➜ {product.name} **Server** ➜ {product.label} **Reason** ➜ {revoke_reason} **Revoked at** ➜ {revoked_at} **Links** PayNow - [Click Here](https://dashboard.paynow.gg/customers/{customer.id}) ``` ## Subscriptions ### Subscription Activated ``` A subscription has been activated. **Customer Info** **Player** ➜ {customer.steam.name} **SteamID** ➜ {customer.steam.id} **Customer ID** ➜ {customer.id} **Email** ➜ {billing_email} **Product Info** **Product** ➜ {product_name} **Billing Sequence** ➜ {billing_cycle_sequence} **Recurring Amount** ➜ {total_amount} (excl. VAT) **Links** PayNow - [Click Here](https://dashboard.paynow.gg/customers/{customer.id}) ``` ### Subscription Renewed ``` A subscription has been renewed. **Customer Info** **Player** ➜ {customer.steam.name} **SteamID** ➜ {customer.steam.id} **Customer ID** ➜ {customer.id} **Email** ➜ {billing_email} **Product Info** **Product** ➜ {product_name} **Billing Sequence** ➜ {billing_cycle_sequence} **Recurring Amount** ➜ {total_amount} (excl. VAT) **Links** PayNow - [Click Here](https://dashboard.paynow.gg/customers/{customer.id}) ``` ### Subscription Canceled ``` A subscription has been canceled. **Customer Info** **Player** ➜ {customer.steam.name} **SteamID** ➜ {customer.steam.id} **Customer ID** ➜ {customer.id} **Email** ➜ {billing_email} **Product Info** **Product** ➜ {product_name} **Billing Sequence** ➜ {billing_cycle_sequence} **Recurring Amount** ➜ {total_amount} (excl. VAT) **Canceled at** ➜ {canceled_at} **Reason** ➜ {cancel_reason} **Links** PayNow - [Click Here](https://dashboard.paynow.gg/customers/{customer.id}) ``` ## Discord Linked to Order ``` A customer has linked their Discord to an order. **Customer Info** **Player** ➜ {customer.steam.name} **Customer ID** ➜ {customer.id} **Product Info** **Product** ➜ {product.name} **Server** ➜ {product.label} **Discord Info** **Username** ➜ {discord_user_name} **DiscordID** ➜ {discord_user_id} **Links** PayNow - [Click Here](https://dashboard.paynow.gg/customers/{customer.id}) ``` The subscription templates above include `{billing_email}`. That's fine for a private staff channel and not fine for a public one. Remove the Email line before pointing any of these at a channel your community can read. # Minecraft Templates Ready-made Discord embed templates for Minecraft stores, ready to copy and paste. Copy-paste embed templates for Minecraft stores. Paste one into **Discord Embed Template** on a [webhook](/integrations-and-commands/webhooks) subscribed to the matching event. Each template belongs to one event, so pasting an Order Completed template onto a webhook subscribed to refunds produces blank fields. Running Rust or another Steam title? Use [Steam Templates](/integrations-and-commands/steam-templates). The templates are otherwise identical but use `{customer.steam.*}` instead of `{customer.minecraft.*}`. Running both? Swap `{customer.minecraft.name}` / `{customer.minecraft.id}` for `{customer.profile.name}` / `{customer.profile.id}` and one template covers both platforms. See [Discord Placeholders](/integrations-and-commands/discord-placeholders). ## General ### Order Completed ``` An order has been completed. **Customer Info** **Player** ➜ {customer.minecraft.name} **UUID** ➜ {customer.minecraft.id} **Customer ID** ➜ {customer.id} **Product Info** **Products** ➜ {product_names} **Server** ➜ {product_tags} **Subscription ID** ➜ {subscription_id} **Price** ➜ {total_amount} **Links** PayNow - [Click Here](https://dashboard.paynow.gg/customers/{customer.id}) ``` ### Refund Completed ``` A product has been refunded! **Customer Info** **Player** ➜ {customer.minecraft.name} **UUID** ➜ {customer.minecraft.id} **Customer ID** ➜ {customer.id} **Order Information** **OrderID** ➜ {order_id} **Amount** ➜ {store_refund_amount} **Links** PayNow - [Click Here](https://dashboard.paynow.gg/customers/{customer.id}) ``` ### Chargeback Created ``` ⚠️ A chargeback has been created! **Customer Info** **Player** ➜ {customer.minecraft.name} **UUID** ➜ {customer.minecraft.id} **Customer ID** ➜ {customer.id} **Order Information** **OrderID** ➜ {order_id} **Amount** ➜ {amount} **Gateway** ➜ {gateway} **Chargeback at** ➜ {chargeback_at} **Links** PayNow - [Click Here](https://dashboard.paynow.gg/customers/{customer.id}) ``` {% hint style="danger" %} **Send chargebacks to a private staff channel.** They need a staff response. Check whether the customer still holds active access, and consider a [ban](/customers/bans). They aren't something to broadcast publicly. {% endhint %} ## Delivery ### Delivery Item Added ``` A product has been added! **Customer Info** **Player** ➜ {customer.minecraft.name} **UUID** ➜ {customer.minecraft.id} **Customer ID** ➜ {customer.id} **Product Info** **Product** ➜ {product.name} **Server** ➜ {product.label} **Product ID** ➜ {product_id} **Links** PayNow - [Click Here](https://dashboard.paynow.gg/customers/{customer.id}) ``` ### Delivery Item Activated ``` Commands for product have been processed! **Customer Info** **Customer ID** ➜ {customer.id} **Player** ➜ {customer.minecraft.name} **UUID** ➜ {customer.minecraft.id} **Product Info** **Product** ➜ {product.name} **Product ID** ➜ {product_id} **Server** ➜ {product.label} **Activated at** ➜ {active_at} **Expires at** ➜ {expires_at} **Links** PayNow - [Click Here](https://dashboard.paynow.gg/customers/{customer.id}) ``` ### Delivery Item Used ``` A product has been used! **Customer Info** **Player** ➜ {customer.minecraft.name} **UUID** ➜ {customer.minecraft.id} **Customer ID** ➜ {customer.id} **Product Info** **Product ID** ➜ {product_id} **Product** ➜ {product.name} **Server** ➜ {product.label} **Links** PayNow - [Click Here](https://dashboard.paynow.gg/customers/{customer.id}) ``` ### Delivery Item Revoked ``` A product has been revoked! **Customer Info** **Player** ➜ {customer.minecraft.name} **UUID** ➜ {customer.minecraft.id} **Customer ID** ➜ {customer.id} **Product Info** **Product ID** ➜ {product_id} **Product** ➜ {product.name} **Server** ➜ {product.label} **Reason** ➜ {revoke_reason} **Revoked at** ➜ {revoked_at} **Links** PayNow - [Click Here](https://dashboard.paynow.gg/customers/{customer.id}) ``` ## Subscriptions ### Subscription Activated ``` A subscription has been activated. **Customer Info** **Player** ➜ {customer.minecraft.name} **UUID** ➜ {customer.minecraft.id} **Customer ID** ➜ {customer.id} **Email** ➜ {billing_email} **Product Info** **Product** ➜ {product_name} **Billing Sequence** ➜ {billing_cycle_sequence} **Recurring Amount** ➜ {total_amount} (excl. VAT) **Links** PayNow - [Click Here](https://dashboard.paynow.gg/customers/{customer.id}) ``` ### Subscription Renewed ``` A subscription has been renewed. **Customer Info** **Player** ➜ {customer.minecraft.name} **UUID** ➜ {customer.minecraft.id} **Customer ID** ➜ {customer.id} **Email** ➜ {billing_email} **Product Info** **Product** ➜ {product_name} **Billing Sequence** ➜ {billing_cycle_sequence} **Recurring Amount** ➜ {total_amount} (excl. VAT) **Links** PayNow - [Click Here](https://dashboard.paynow.gg/customers/{customer.id}) ``` ### Subscription Canceled ``` A subscription has been canceled. **Customer Info** **Player** ➜ {customer.minecraft.name} **UUID** ➜ {customer.minecraft.id} **Customer ID** ➜ {customer.id} **Email** ➜ {billing_email} **Product Info** **Product** ➜ {product_name} **Billing Sequence** ➜ {billing_cycle_sequence} **Recurring Amount** ➜ {total_amount} (excl. VAT) **Canceled at** ➜ {canceled_at} **Reason** ➜ {cancel_reason} **Links** PayNow - [Click Here](https://dashboard.paynow.gg/customers/{customer.id}) ``` ## Discord Linked to Order ``` A customer has linked their Discord to an order. **Customer Info** **Player** ➜ {customer.minecraft.name} **Customer ID** ➜ {customer.id} **Product Info** **Product** ➜ {product.name} **Server** ➜ {product.label} **Discord Info** **Username** ➜ {discord_user_name} **DiscordID** ➜ {discord_user_id} **Links** PayNow - [Click Here](https://dashboard.paynow.gg/customers/{customer.id}) ``` The subscription templates above include `{billing_email}`. That's fine for a private staff channel and not fine for a public one. Remove the Email line before pointing any of these at a channel your community can read. # API Keys Create and manage API tokens for headless storefronts, imports and automation. API keys let you drive PayNow programmatically: build a headless storefront, import packages, or wire your store into other systems. Endpoints are documented at [docs.paynow.gg](https://docs.paynow.gg/). *Dashboard → Integrations → API Keys. Needs `apikey_read`.* ## Creating a key 1. Go to **Integrations → API Keys**. 2. Click **Create**. 3. Give it a **name** and assign a **role**. The key's page then shows the token, along with options to reset it and when it was last modified.
The API Keys page listing two keys with their names, roles and last-modified dates.
## The role is the important field {% hint style="danger" %} **A key can do everything its role can do.** The role is the entire security boundary; there is no second layer. Give each key the narrowest role that lets it work. A key that only reads your catalogue for a storefront should not be able to issue refunds, edit products, or read customer data. If it leaks, the role decides whether you have an inconvenience or an incident. See [Roles](/store-settings/roles) and [Permissions Reference](/store-settings/permissions). {% endhint %} ## Naming keys so you can revoke safely Name each key after where it runs, not what it does: `storefront-prod`, `ci-import`, `discord-bot`, `analytics-script`. When you reset one, the name is the only thing telling you what will break. A key called `api key 1` makes that a guess. Use one key per consumer. Sharing a key across three systems means one reset takes all three down, and a leak gives you no way to tell which one leaked. ## Keeping keys safe Never commit a key to a repository; it stays in the git history after you delete the line, so use environment variables or a secrets manager. Never paste one into Discord or a support ticket, screenshots included. Never put one in frontend code, since anything shipped to a browser is public, so a headless storefront needs a server-side layer holding the key. Reset on any suspicion of exposure, or when someone with access leaves. ## Resetting Resetting issues a new token and **invalidates the old one immediately**. Anything using the old value stops working at once, so update your consumer first or accept the downtime. # Payouts Withdraw your earnings, and track each payout through to settlement. Where you withdraw what your store has earned. [Billing](/payments-and-payouts/billing) is the opposite direction: what PayNow charges you. *Dashboard → Billing → Payouts. Owner-only: it isn't permission-gated, so no role grants it, not even a fully-privileged Administrator. See* [*Account Payouts vs Store Payouts*](/payments-and-payouts/account-vs-store-payouts)*.* ## First time here A new store shows a warning: *"You are not eligible to receive payouts, please check your payout onboarding status."* Click **Setup Payouts** in the top right and complete onboarding. Do this early. Payout onboarding has to be approved before your store can go live, so it gates your launch rather than just your first withdrawal, and approval is not instant. {% hint style="warning" %} **Get every detail about yourself or your business right first time.** Corrections after submission are slow, and each round trip adds to the wait before you can sell at all. See [Setting Up Your Payout Account](/getting-started/payout-account) and [Tax Forms](/getting-started/tax-forms). {% endhint %}
The Payouts page before onboarding, showing the eligibility warning and Setup Payouts button.
## Withdrawing funds 1. Click **Withdraw Funds** in the top right. 2. Enter the amount. 3. Submit. The payout appears on the main Payouts page with a **timeline** of the stages it moves through, plus details such as IDs, name and amount. Filter by payout type and time range using the controls in the top right of the payouts section.
The Payouts page showing the available and settling balances, the Withdraw Funds button, and a payout list with one payout Processing and one Completed.

The step-by-step payout timeline is on the payout's own page — open a row to see it.

## Your balance is not your revenue Three different numbers get confused constantly. | Number | Where | What it is | | ----------- | -------------------------------------------------- | -------------------------------------------- | | **Sales** | [Dashboard](/analytics/dashboard) | What customers paid, gross | | **Net** | [Transactions](/payments-and-payouts/transactions) | After tax, gateway fees and platform fees | | **Balance** | Here | Net that has **settled** and is withdrawable | A sale completed today isn't withdrawable today. It has to settle first, and **Settles In** on [Transactions](/payments-and-payouts/transactions) tells you when. If your balance looks low against your sales figure, work down that table before assuming something is wrong. Tax is usually the largest single difference, and it was never your money. ## Practical notes Start onboarding before you need the money. Approval isn't instant, and the worst time to find a document problem is when you're relying on the payout. Compare fees before choosing a method. A wire costs around fifteen times an ACH for the same money, and **PayPal is USD stores only**. The full fee table is in [Setting Up Your Payout Account](/getting-started/payout-account). Don't use payouts as currency exchange. Take the payout in your local currency where that option exists. The FX rates are unfavourable and PayNow earns nothing from them. # Transactions Every transaction saved to your payout account, with a full fee breakdown and CSV export. Every transaction saved to your **payout account**. A payout account belongs to an account rather than a store, so this list spans **all stores you own**, and the Store column tells you which one each transaction came from. *Dashboard → Billing → Payouts → Transactions. Owner-only, like the rest of* [*Payouts*](/payments-and-payouts/payouts)*. See* [*Account Payouts vs Store Payouts*](/payments-and-payouts/account-vs-store-payouts)*.*
The Transactions list with the fee breakdown tooltip showing gross, taxes, gateway fees, platform fees and net.

Hover any amount to see exactly where the money went.

## Reading the table | Column | What it tells you | | ---------------- | ----------------------------------------------------------------------------------------------- | | **ID** | The transaction identifier. Quote this when contacting support about a specific payment. | | **Store** | Which of your stores generated it. Present because one payout account can serve several stores. | | **Type** | What kind of transaction it is. Filter by this using **Transaction Type** in the top right. | | **Description** | Human-readable summary, for example *Product purchase*. | | **Amount** | The **net** figure, what actually reaches you. Hover it for the full breakdown. | | **Completed At** | When the transaction completed. | | **Settles In** | How long until the funds settle and become withdrawable. | ## The fee breakdown Hovering an amount expands it into five lines. | Line | What it is | | ----------------- | ----------------------------------------------------------------------------------------------------------- | | **Gross** | What the customer paid in total. | | **Taxes** | Sales tax / VAT collected and remitted. PayNow handles this as merchant of record. It was never your money. | | **Gateway Fees** | Charged by the payment processor for handling the card. | | **Platform Fees** | PayNow's fee. | | **Net** | What lands in your payout account. | $$Net = Gross - Taxes - Gateway\ Fees - Platform\ Fees$$ Net looks low against your product price because a customer paying $34.49 for a product you priced lower is paying your price plus tax. Tax is the largest deduction in most regions. Compare **Platform Fees** against gross to see what PayNow actually costs you. ## Exporting to CSV Click **Export** to download transaction history for accounting or bookkeeping.
The Export Transactions dialog with date range, store filter and Include Payouts option.
| Field | What it does | | ------------------- | ------------------------------------------------------------------ | | **From** | Start of the range. **Inclusive, in UTC.** | | **To** | End of the range. **Inclusive, in UTC.** | | **Store** | Restrict to one store. Set to **All stores** to disable filtering. | | **Include Payouts** | Whether payout transactions appear alongside the rest. | {% hint style="warning" %} **Two things to watch when exporting for accounts:** 1. **Dates are UTC, not your local timezone.** Export a calendar month while you aren't on UTC and the boundary days won't match your local month. 2. **The store filter does not apply to payouts.** Select a single store *and* tick Include Payouts and the payout rows are still unfiltered, because payouts belong to the account rather than to any one store. A single-store export isn't a complete picture of that store's cash movement. {% endhint %} # Account vs Store Payouts Payout accounts belong to accounts, not stores, which changes what multi-store owners and teams should expect. Two places in the dashboard have "Payouts" in the name, and confusing them causes a lot of "where is my money?" tickets. The rule: payout accounts belong to **accounts**, not stores. If you own the store, its funds go to **your** payout account. ## The two pages | Page | Where | What it is | | --------------------- | ------------------ | --------------------------------------------------------------------------------------------- | | **Account → Payouts** | `/account/payouts` | Your personal payout account: the identity, method and tax details PayNow pays *you* through. | | **Billing → Payouts** | `/payouts` | The [payouts view](/payments-and-payouts/payouts) in the context of a store. Owner-only. | Two views onto the same money. The payout account is the destination; the store is one of possibly several sources feeding it. ## If you own several stores All of them settle into one payout account, yours. You don't set payouts up per store, and you don't receive separate payments per store. That's why [Transactions](/payments-and-payouts/transactions) has a **Store** column: it's an account-level ledger. For separate payouts per store, with different bank accounts, legal entities or bookkeeping, the stores have to be owned by different accounts. One account can't split its payouts across destinations. ## If you are a team member, not the owner You won't see Payouts at all. It's owner-only and not permission-gated, so no role grants it, including a fully-privileged Administrator role. Store revenue settles to the owner's payout account. If your [team](/store-settings/team-members) needs revenue visibility without payout access, give them `stats_revenue_read` for [Analytics](/analytics/analytics) instead. ## If you are an affiliate with no store You still have a payout account. That's the point of the payouts-only signup path: you can receive settlements without ever creating a store. See [Setting Up Your Payout Account](/getting-started/payout-account). ## Consequences to plan for {% hint style="warning" %} **Transferring store ownership transfers where the money goes.** Move ownership to another account and subsequent revenue settles to *their* payout account. Don't transfer ownership casually. {% endhint %} A store named after your community doesn't change whose legal identity receives the funds. The identity, method and tax details on the payout account are what PayNow pays out against. **The name on your verified ID and the name on your payout details have to match.** If they don't, you'll be asked to correct one of them. Paying into a company account is fine, but you have to be the owner of that company. Paying into a friend's account, a parent's account, or a business you don't own is not. Tax documents follow the account. US recipients get a 1099-K against the payout account, covering all stores that settled into it, not one per store. # Payout Problems Switching payout method, paying into a bank in another country, and what to do when a payout has not arrived. The setup path is in [Setting Up Your Payout Account](/getting-started/payout-account). This page is the things that go wrong afterwards. *Dashboard → Payouts → **Setup Payouts**. Owner only.* ## Switching payout method You can only have one payout method active at a time. Changing it means going back through the Tipalti window rather than picking from a list in the dashboard. 1. Click **Setup Payouts** again. 2. Go to the payment method page inside the window. 3. Change the method at the top. The new method goes through review again, so allow for that before you need the money. Two things catch people out. **PayPal pays in USD only**, so a store on another currency has to use a bank transfer. And **the name on your PayPal account has to match your onboarding details exactly**, character for character, or the payout fails verification. ## Your bank is in a different country from your address This is possible, but the option is hidden until it is switched on for your store. Ask PayNow support to enable it, giving your store ID. Once it is on, reopen the payout onboarding window and you will see a new blue underlined link on the first page, below the postal code, for choosing the bank account country. The same applies to services like Wise, where the account usually sits in a different country from you. ## Cryptocurrency payouts Not supported. It has been looked at and it is planned, but there is no date, and there is no workaround in the meantime. ## A payout has not arrived Tipalti marking a transfer as sent is not the same as the money landing. Allow **about 24 hours** after that point, and a little longer for a first payout to a new account. If it has been longer than a day, open a ticket with your store ID and the date you requested it. PayNow can raise it with Tipalti, though that is not PayNow's system and answers take at least a day to come back. ## You received less than you expected Check who did the currency conversion before assuming a fee is wrong. {% hint style="warning" %} **Letting Tipalti convert costs 2% to 4%.** Where your bank can accept the payout currency and convert it itself, compare the two before choosing. On a large payout the difference is substantial. {% endhint %} You can see which side converted in the Tipalti window. The fee tables for each method are in [Setting Up Your Payout Account](/getting-started/payout-account#what-the-method-costs-you). A payout that is smaller than your sales for the period is usually settlement rather than fees. [Transactions](/payments-and-payouts/transactions) breaks down gross, tax, gateway and platform fees per order. ## Your wallet does not move Wallets belong to accounts, not to stores. Transferring a store leaves the balance where it is, and only sales made after the transfer pay into the new owner's wallet. Withdraw before handing a store over. See [Transfer Store Ownership](/store-settings/transfer-ownership). # Billing Your PayNow plan, billing details and invoices, meaning what PayNow charges you. Billing is what **PayNow charges you**. [Payouts](/payments-and-payouts/payouts) is what **PayNow pays you**. Two pages, opposite directions. *Dashboard → Billing → Billing. Needs `billing_manage`.* ## Adding billing details A new store shows a warning at the top until billing details are provided. Click **Billing Details** in the top right, complete the form, and the warning clears.
The Billing page showing the missing-details warning and the Billing Details button.
## The three sections | Section | What it shows | | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Tier Details** | Your current plan, your usage limit within that tier, and your platform fees. Click **Change Plan** to browse and select a different package. | | **Subscription Status** | The status of your PayNow subscription. | | **Invoices** | Every invoice PayNow has issued you, for your own bookkeeping. For sales-side records, export from [Transactions](/payments-and-payouts/transactions) instead. |
The plan card showing the current plan, revenue limit usage and platform fees, with the Change Plan button.
## The plans Four plans. The higher the plan, the lower the percentage PayNow takes from each sale, so the subscription partly pays for itself as you grow. | Plan | Platform fee | Monthly sales limit | | -------------- | ------------ | ------------------- | | **Free** | 3.5% | Up to $2,000 | | **Pro** | 3% | Up to $5,000 | | **Business** | 2.5% | Unlimited | | **Enterprise** | Custom | Custom | {% hint style="warning" %} **Free and Pro cap your monthly sales.** They are not soft targets. Watch the usage figure in **Tier Details** as you approach the limit, because a store that hits its cap mid-month is a store that stops taking money. {% endhint %} Prices are on [paynow.gg/pricing](https://paynow.gg/pricing) and vary with monthly or annual billing, so check there rather than relying on a figure quoted here. ## What each plan adds Everything in a lower plan is included in the ones above it. | Plan | Adds | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | **Free** | Full chargeback protection, headless API, custom templates, worldwide payment processing, basic statistics | | **Pro** | [Custom domain](/your-webstore/webstore), [detailed statistics](/analytics/analytics), [affiliate links](/marketing/affiliate-links) | | **Business** | [Custom checkout branding](/your-webstore/branding), [regional pricing](/products/creating-a-product#regional-pricing) | | **Enterprise** | Talk to PayNow about what you need | The dashboard badges the Business features as *Business Plan Feature* rather than naming the plan. Anything not named above is in Free. Detailed statistics add *Popular Times of Day* and *Order Volume By Product*, which tell you when to announce a sale and which price points work. Compare that against your monthly revenue on the [Dashboard](/analytics/dashboard) before you switch. ## Platform fees versus your plan {% hint style="warning" %} **Your plan and your platform fees are separate charges.** The plan is a recurring charge for the tier. Platform fees are a percentage of each sale, shown per transaction on [Transactions](/payments-and-payouts/transactions). A bill that looks higher than expected is usually both. {% endhint %} Each tier carries its own platform fee rate, shown next to the tier when you click **Change Plan**, so compare the fee rates as well as the subscription price before you switch. # Dashboard The headline numbers for your store, covering lifetime sales, today, this month, and average order value. The Dashboard is the first thing you see when you open a store. It answers one question fast: is the store doing better or worse than it was? *Dashboard → Analytics → Dashboard, the sidebar's home item. No permission is needed to open it, so every team member sees it, and it's on every plan — but the revenue figures on it need `stats_revenue_read` and are blurred without it. Deeper reporting lives in* [*Analytics*](/analytics/analytics)*, which needs a paid plan.*
The store dashboard showing lifetime sales, period tiles and the weekly revenue chart.
## The headline tiles | Tile | What it means | What to watch for | | ----------------------- | -------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | **Lifetime Sales** | Total earnings since the store opened. | A vanity number day to day, but the one to quote when valuing the store or negotiating with sponsors. | | **Today** | Earnings so far today. | Compare against the same weekday last week, not against yesterday. Game store revenue is strongly weekly. | | **This Month** | Earnings month to date. | Pace it: at day 10 of 30, you should be near a third of last month's total. | | **Average Order Value** | Mean value per order. | The number most within your control. [Upselling](/marketing/upselling) and [Tier Groups](/products/tier-groups) move it directly. | {% hint style="warning" %} **These are sales figures, not payout figures.** They show what customers paid, before tax, gateway fees and platform fees. What actually reaches you is the **Net** figure on [Transactions](/payments-and-payouts/transactions). Expect a sizeable gap, most of it tax. {% endhint %} ## Charts **Weekly Revenue** shows the shape of your week. Most game communities peak at weekends and after content updates. Once you know your own shape, schedule [Sales](/marketing/sales) and announcements to land just before a peak rather than during a trough. **Sales Today** is a live tracker, useful during a launch or sale and largely noise otherwise. **Top products this month** tells you what is carrying the store. One or two products commonly account for most revenue. Check it before you spend a weekend building a third. ## Reading it well Compare like with like: weekday against the same weekday, month against the same month last year if you have the history. Raw day-on-day comparisons mislead. Expect a spike then a decay after any promotion, so judge a sale on the full week. A flat month isn't a bad month if your subscriber base is growing, because recurring revenue shows up as stability before it shows up as growth. Average order value falling while orders rise usually means a discount worked but ate the margin. # Analytics Volume and recurring-payment reporting that shows when your customers buy, what they buy, and whether subscribers are staying. Where the [Dashboard](/analytics/dashboard) tells you *how much*, Analytics tells you *when*, *what* and *whether it is holding*. It splits into **Volume** and **Recurring Payments**. *Dashboard → Analytics. The sidebar item needs `stats_revenue_read`. The reporting itself needs the **Pro** plan or above; without one the page still opens but its charts are blurred behind an upgrade prompt. See* [*paynow.gg*](https://paynow.gg/) *for plans, or* [*Billing*](/payments-and-payouts/billing) *to change yours.* Set a time range with the filters at the top before reading anything; the default may not be what you want. ## Volume
The Volume section of Analytics showing gross and net earnings, popular times of day, and order volume by product.
| Panel | What it shows | How to act on it | | --------------------------- | -------------------------------------- | ------------------------------------------------------------------------------------------------------------ | | **Gross and net earnings** | Revenue before and after deductions. | The gap is tax and fees. Watch the ratio, not just the top line. | | **Popular Times of Day** | When orders actually happen. | Schedule announcements, sale launches and Discord pings to land just *before* your peak. | | **Order Volume by Product** | Which products sell, by gross revenue. | Read alongside order counts. A cheap product can dominate the order count while contributing little revenue. | Popular Times of Day is the panel most stores ignore and the one that changes results fastest. Announcing a sale at your convenient hour rather than your community's active hour costs you money every time. Find the peak, schedule against it. ### Reading price performance Order Volume by Product also tells you which *price points* work. If a $19.99 product consistently outsells a $24.99 one by more than the price gap justifies, you've found a ceiling. That informs how you price the next thing you build, and whether a [tier ladder](/products/tier-groups) sits above or below it. Monthly figures are computed on a fixed timezone, so if yours differs, the month starts and ends mid-day for you and single days can look shifted against your own records. Compare periods, not individual days. ## Recurring Payments Only meaningful if you sell subscription products, and worth close reading if you do. Recurring revenue behaves nothing like one-off sales.
The Recurring Payments section of Analytics showing monthly recurring revenue, active and new subscriptions, churned revenue and churned subscriptions, active subscriptions by product, and top customers by MRR.

The dashboard labels the churn panels Churned Subscriptions and Churned Revenue.

| Panel | What it shows | How to act on it | | ------------------------ | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | **Active subscriptions** | How many people are currently paying you monthly. | The health metric for the whole store. Track its direction, not its value. | | **Cancellations** | Who is leaving. | A cancellation spike almost always follows a change: a price rise, a server wipe, a broken perk. Look at what you shipped that week. | | **Top products** | Which subscriptions retain. | Build more like the ones that hold; investigate the ones that churn. | Read both panels together. Twenty new subscribers against eighteen cancellations is near-flat, not growth, and the active-subscriptions line already nets that out for you. ### If cancellations are climbing Work through these in order: 1. **Did delivery break?** A subscriber whose perks stopped working cancels quickly and quietly. Check [Game Servers](/integrations-and-commands/game-servers) and the product's commands. 2. **Did renewals fail?** Expired cards look like churn but are recoverable. See [Subscriptions](/orders-and-subscriptions/subscriptions). 3. **Did you change something?** Price, perks, server rules, a wipe. 4. **Is the value still there?** Long-tenured subscribers churn when the perk stops feeling special. [Tier Groups](/products/tier-groups) give them somewhere to go next. # Settings Store details, platform, integration type, payment methods, card restrictions and promo stacking. Store-wide configuration. A few of these settings are hard to reverse once customers have started buying. *Dashboard → Store → Settings. Needs `store_update`.* ## Store details | Field | What it does | | -------- | -------------------------------------------------------------------------------------------------- | | **ID** | Unique identifier for your store, used with the [PayNow API](/integrations-and-commands/api-keys). | | **Name** | Appears on your webstore, checkout pages **and payment descriptors**. | | **Slug** | URL-friendly name identifying your store in web addresses. | {% hint style="warning" %} **Store Name shows on bank statements.** It is the payment descriptor customers see when they check their card statement weeks later. A name they do not recognise becomes a chargeback. Use the name your community actually calls you, not a legal entity name. {% endhint %} ## Platform Select your platform: Rust, Minecraft and so on. This optimises available features and integrations. {% hint style="danger" %} **Switching to or from a third-party integration affects your platform fees and available functionality.** The dashboard raises a **Platform Change** warning when you do. Only proceed if you completely understand what will happen, and check you are not violating any terms set by the third-party integration: making changes without proper authorization may result in your store being locked. {% endhint %} ## Support | Field | Who sees it | | ----------------- | ---------------------------------------------- | | **Support Email** | Customers. Where they contact you. | | **Contact Email** | PayNow only. How we reach you about the store. | Point Support Email at an inbox a human reads. Unanswered customers dispute charges. ## Integration | Type | Use when | | --------------------------- | ------------------------------------------------- | | **Hosted Webstore** | You use PayNow's hosted storefront. Most stores. | | **Headless API** | Fully custom integration via the API. | | **Third-Party Integration** | A third-party platform integrates PayNow for you. | ## Payment Settings Global payment options, including showing all payment methods for subscriptions and store-wide tax-inclusive pricing. The two [Adaptive Currency](/store-settings/adaptive-currency) toggles live here too, both on by default. ## Payment Restrictions Prepaid cards are disposable and can run out of funds mid-billing-cycle, so they drive fraud, trial abuse and churn. | Option | Effect | | -------------------------------- | ----------------------------------------------------------------------------------------------------- | | **Accept all prepaid cards** | Allowed everywhere. | | **Block for trial periods only** | Cannot start a trial with a prepaid card. One-time purchases and regular subscriptions still allowed. | | **Block for all subscriptions** | Cannot be used for any subscription, including trials. One-time purchases still allowed. | Stores selling recurring products usually pick **Block for all subscriptions**. It removes churn from expired balances while one-time purchases stay frictionless. Prepaid cards are also the standard tool for farming free [trials](/orders-and-subscriptions/trials). ## Checkout Settings How coupons and gift cards combine at checkout. | Option | Effect | | --------------------------- | --------------------------------------------------------------------------------------------------------- | | **Disable stacking** | One promo only. No combining anything. | | **Gift Card stacking only** | Multiple gift cards on one order, but coupons never combine, not with each other and not with gift cards. | | **Enable stacking** | Coupons and gift cards freely combine. | **Gift Card stacking only** is the middle ground: several gift card balances on one purchase, while your [coupon](/marketing/coupons) discounts stay predictable. Work out your worst case before choosing **Enable stacking**. A percentage coupon on top of an active [sale](/marketing/sales) can add up to a far larger discount than you intended. ## Payment Methods Organised into **Global** and regional tabs. Your store can offer regional payment methods regardless of its base currency: Klarna, Cash App Pay, Amazon Pay, iDEAL, Wero, BLIK, Przelewy24, MB WAY, MobilePay, Revolut Pay, Satispay, TWINT and UPI. Customers only ever see the methods available in their own region. Enable the ones that matter in your markets. A large share of buyers in the Netherlands use iDEAL and in Poland BLIK in preference to cards, and a card-only store loses them silently.
The store Settings page showing store details, platform, support emails and integration type.
# Adaptive Currency Show and charge prices in your customer's local currency, at no cost and no FX risk to you. Adaptive Currency shows customers prices in their own currency and lets them pay in it. A store priced in EUR shows USD to a customer browsing from the US. It is on by default and free on every plan, including Free. *Dashboard → Store → Settings → Payment Settings. Needs `store_update`.* ## How it works PayNow detects the customer's country, from their IP address or from a country header your integration passes, and converts prices into that region's currency. At checkout the customer can switch back to your base currency at any point. ## What it changes | Effect | Why | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------- | | **Higher payment approval rates** | Card networks approve local-currency charges more often than cross-currency ones. You never see the declines you avoided. | | **No foreign transaction fee for your customer** | Their bank adds no FX charge, and PayNow's rates beat most banks'. | | **Regional payment methods appear** | iDEAL, Klarna, Cash App Pay and others can show for customers in their region even when your base currency differs. | | **Less hesitation** | Familiar numbers in a familiar currency. | ## Who carries the exchange-rate risk PayNow does, entirely. If rates move between checkout and settlement, or on refunds and renewals, PayNow absorbs the difference. There is no extra fee to you: the conversion cost is built into the rate shown to the customer, and your [payouts](/payments-and-payouts/transactions) still settle in your base currency. ## Supported currencies | Currency | Region | | -------- | -------------- | | **USD** | United States | | **GBP** | United Kingdom | | **EUR** | Eurozone | | **CAD** | Canada | | **AUD** | Australia | More are added over time. Customers outside a supported region see your base currency, exactly as they would with the feature off. ## Configuration Two controls in [Settings](/store-settings/store) → Payment Settings, both on by default. | Toggle | What it does | | ---------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Enable Adaptive Currency** | Master switch. Off disables the feature entirely. | | **Show Adaptive Currency on storefront** | Whether customers see local currency on the storefront by default. Off means the storefront shows your base currency, but customers can still switch at checkout. |
The Payment Settings section showing the two Adaptive Currency toggles enabled.
{% hint style="warning" %} **Turning the storefront toggle off costs conversions.** Customers meet a different number at checkout than the one that persuaded them. If you want one advertised price for announcements and marketing, keep both toggles on and quote your base currency with a note that local pricing is available. {% endhint %} ## Custom storefronts Adaptive Currency works automatically provided you pass the recommended country header documented in the API reference. On pages showing past order or subscription amounts, such as an order history page, use the **`presentment_`** fields on the order and subscription objects. Customers then see the amount they actually paid, in the currency they paid it in. → [PayNow API documentation](https://docs.paynow.gg) # Team Members Invite staff to your store and control what they can do. Bringing people in to help is necessary as a store grows. Doing it carelessly is how stores get drained. *Dashboard → Access → Team Members. Needs `invite_manage`.* {% hint style="danger" %} **Give the narrowest role that lets someone do their job.** Only owners should have full access. A moderator answering tickets needs to view orders and customers, not to issue refunds, edit products or create API keys. Every extra permission is a way for a mistake or a compromised account to cost you money. {% endhint %} ## Inviting someone 1. Go to **Access → Team Members**. 2. Click **Invite New Member** in the top right. 3. Enter their **email address**. 4. Select the **role** to apply. 5. Send. Build the role on the [Roles](/store-settings/roles) page first, then invite.
The Team Members page with the invite dialog open, showing the email field and role selector.
Click any member to see their name, when they were added, and their role. From there you can change their role or remove them from the store. ## Payouts is not grantable No role grants access to Payouts. It is owner-only rather than permission-gated, so even a fully-privileged Administrator cannot open it. If someone needs revenue visibility without payout access, give them `stats_revenue_read` for [Analytics](/analytics/analytics). → [Account Payouts vs Store Payouts](/payments-and-payouts/account-vs-store-payouts) ## A sensible starting structure | Role | Who | Roughly what they need | | ----------------- | ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | **Owner** | You | Everything. Cannot be delegated. Does not make someone the store's owner: see [Transfer Store Ownership](/store-settings/transfer-ownership). | | **Administrator** | Co-owner you trust with money | Products, refunds, marketing, team | | **Moderator** | Trusted staff | View orders, customers, subscriptions; issue [bans](/customers/bans) | | **Support** | Ticket handlers | View orders and customers only | Support staff resolve most tickets with read access alone. The [order timeline](/orders-and-subscriptions/orders) and a customer's [inventory](/customers/managing-customers) answer most questions without any write permission. ## Reviewing access Do this quarterly, and immediately when someone leaves. 1. Remove members who are no longer involved, on the day they leave. 2. Check nobody has accumulated permissions from a temporary task. 3. Reset any [API keys](/integrations-and-commands/api-keys) that person had access to. Removing them from the team does **not** invalidate a key they copied. # Transfer Store Ownership How to hand a store to a new owner, what PayNow needs from both people, and what does not move with it. A store belongs to one account. Selling the community, handing it to a co-owner, or moving it off a parent's account all mean transferring that ownership. Transfers are done by PayNow support. There is no button for it in the dashboard. ## The Owner role is not ownership Giving someone the **Owner** role in [Team Members](/store-settings/team-members) gives them full access to the store. It does not make them the store's owner. The account that created the store still owns it, still receives the payouts, and is still the only person who can request a transfer. This catches people out when a team changes hands. Check who actually owns the store before agreeing anything. ## Before you ask Both people need to be ready, or the request stalls. **The new owner must:** 1. Have a PayNow account. 2. Be invited to the store as a [team member](/store-settings/team-members), and have accepted the invite. 3. Have completed identity verification (KYC) on their own account. 4. Have [payouts](/payments-and-payouts/payouts) set up on their own account. Steps 3 and 4 are the ones that hold transfers up. They take days, not minutes, so start them before requesting the transfer. ## Requesting the transfer Contact PayNow support with all of the following: | From the current owner | From the new owner | | -------------------------- | ------------------------------------- | | Store ID | Full name | | Full name | Email address on their PayNow account | | Email address on the store | | The request has to come from the current owner. Support will not act on a request from the person receiving the store, whatever access they already have. ## What does not move {% hint style="warning" %} **The wallet stays with the account.** Wallets belong to accounts, not to stores, so the balance sitting in the old owner's wallet does not transfer. Only sales made after the transfer pay into the new owner's wallet. Withdraw your balance before handing the store over. {% endhint %} Also worth settling before the transfer: * **Currency cannot be changed.** A store's currency is fixed when it is created. If the new owner needs a different one, they have to create a new store instead. * **Payouts follow the owner.** Once transferred, the store pays into the new owner's account. * **Team access stays as it is.** Existing members keep their roles. Review them afterwards. # Roles Build named permission sets to assign to team members. A role is a named bundle of permissions. You assign roles to people rather than picking permissions per person, so access stays consistent and reviewable. Only store owners should end up with full permissions. Everyone else gets limited, task-specific access. *Dashboard → Access → Roles. Needs `role_read`.* ## Creating a role 1. Go to **Access → Roles**. 2. Click **Create** in the top right. 3. Name the role, give it a short description, and choose the permissions to assign. 4. Click **Create**. Full list: [Permissions Reference](/store-settings/permissions).
The Roles page with the New Role dialog open, showing name, description and permission checkboxes.
## Where roles are applied Not here. Roles are assigned on the [Team Members](/store-settings/team-members) page, when inviting someone or when editing an existing member's access. Creating a role does nothing on its own until it is assigned. ## Designing roles Name roles by job, not by power level. *Support Lead*, *Billing Viewer* and *Content Editor* tell you who the role is for. *Level 2* does not. Create several narrow roles rather than one broad one. A member holds a single role, so the one you assign is the whole of their access. Start read-only and add permissions as people need them. Granting is easy; discovering that someone had delete rights for six months is not. Review roles regularly so access matches what people actually do now. ### Roles worth having | Role | Include | Deliberately exclude | | ------------------ | ------------------------------------- | ------------------------------------------- | | **Support** | View orders, customers, subscriptions | Refunds, product edits, API keys | | **Moderator** | Support's permissions + bans | Anything financial | | **Content Editor** | Products, tags, webstore, branding | Customers, orders, billing | | **Marketing** | Sales, coupons, gift cards, analytics | Products, refunds, team | | **Administrator** | Most things | Nothing you would not survive being misused | {% hint style="danger" %} **Anyone who can assign roles can grant themselves everything else.** Treat **Assign Roles** as equivalent to full access. Think just as hard before granting **Create Refunds** (moves money out), **Manage Orders** (changes order state), **Delete Products** (destroys catalogue and complicates order history), **Create/Update API Keys** (a key can be copied and used after the person leaves) and **Manage Billing** (changes your plan and payment details). {% endhint %} Keys created under those permissions stay valid until you reset them on the [API Keys](/integrations-and-commands/api-keys) page. # Permissions Every permission you can assign to a role, grouped by area, with the risky ones flagged. Every permission available when building a [role](/store-settings/roles). {% hint style="danger" %} **Permissions marked 🔴 can cost you money or access if misused.** Grant them only to people you would trust with your bank details. {% endhint %} ## Store | Permission | Allows | | ---------------- | ---------------------- | | **View Store** | Viewing store settings | | **Update Store** | Editing store settings | ## Product | Permission | Allows | | ---------------------- | ---------------------------------------------------------------------- | | **View Products** | Viewing products | | **Create Product** | Creating new products | | **Update Products** | Updating products | | 🔴 **Delete Products** | Deleting products — complicates order history and active subscriptions | ## Customer | Permission | Allows | | ---------------------- | ------------------------------------------------------------ | | **View Customers** | Viewing customers | | **Create Customers** | Creating new customers | | **Update Customers** | Updating customers | | **Manage Inventories** | Managing customer inventories — granting and revoking access | ## Role | Permission | Allows | | ------------------- | -------------------------------------------------------------------------------------------------------- | | **View Roles** | Viewing roles | | **Create Roles** | Creating new roles | | **Update Roles** | Updating roles | | **Delete Roles** | Deleting roles | | 🔴 **Assign Roles** | Assigning roles to members — **effectively full access**, since the holder can grant themselves anything | ## Game Server | Permission | Allows | | ------------------------------- | --------------------------------------- | | **View Game Servers** | Viewing game servers | | **Create Game Servers** | Creating game servers | | **Update Game Servers** | Updating game servers | | **Delete Game Servers** | Deleting game servers | | **Resend Game Server Commands** | Resending commands — useful for support | ## API Key | Permission | Allows | | ---------------------- | ---------------------------------------------------------------- | | **View API Keys** | Viewing API keys | | 🔴 **Create API Keys** | Creating keys — a copied key still works after the person leaves | | 🔴 **Update API Keys** | Updating keys | | **Delete API Keys** | Deleting keys | ## Branding | Permission | Allows | | ------------------- | ----------------------- | | **Update Branding** | Updating store branding | ## Order | Permission | Allows | | -------------------- | ------------------------------------- | | **View Orders** | Viewing orders | | **Create Orders** | Creating orders | | 🔴 **Manage Orders** | Managing orders — changes order state | ## Subscription | Permission | Allows | | ------------------------ | ------------------------ | | **View Subscriptions** | Viewing subscriptions | | **Cancel Subscriptions** | Cancelling subscriptions | ## Payment | Permission | Allows | | -------------------------- | -------------------------------- | | **View Payments** | Viewing payments | | **Manage Payment Methods** | Managing payment method settings | ## Refund | Permission | Allows | | --------------------- | ------------------------------------------------------ | | **View Refunds** | Viewing refunds | | 🔴 **Create Refunds** | Creating refunds — **moves money out of your account** | ## Coupon | Permission | Allows | | ------------------ | ---------------- | | **View Coupons** | Viewing coupons | | **Create Coupons** | Creating coupons | | **Update Coupons** | Updating coupons | | **Delete Coupons** | Deleting coupons | ## Sale | Permission | Allows | | ---------------- | -------------- | | **View Sales** | Viewing sales | | **Create Sales** | Creating sales | | **Update Sales** | Updating sales | | **Delete Sales** | Deleting sales | ## Gift Card | Permission | Allows | | ------------------------ | ----------------------------------------------------------------------- | | **View Gift Cards** | Viewing gift cards | | 🔴 **Create Gift Cards** | Creating gift cards — **a gift card is closer to cash than a discount** | | **Update Gift Cards** | Updating gift cards | | **Cancel Gift Cards** | Cancelling gift cards | ## Tag | Permission | Allows | | --------------- | ------------- | | **View Tags** | Viewing tags | | **Create Tags** | Creating tags | | **Update Tags** | Updating tags | | **Delete Tags** | Deleting tags | ## Webstore | Permission | Allows | | --------------------------- | ------------------------- | | **View Webstore** | Viewing webstore details | | **Update Webstore Details** | Updating webstore details | | **Delete Webstore Details** | Deleting webstore details | ## Webhook | Permission | Allows | | ------------------------ | --------------------------------- | | **View Webhooks** | Viewing webhooks | | **Create Webhooks** | Creating webhooks | | **Update Webhooks** | Updating webhooks | | **Delete Webhooks** | Deleting webhooks | | **View Webhook History** | Viewing webhook execution history | ## Affiliate | Permission | Allows | | ----------------------------- | ------------------------------------------------------------ | | **View Affiliate Links** | Viewing affiliate links | | 🔴 **Create Affiliate Links** | Creating affiliate links — commits you to ongoing commission | | **Update Affiliate Links** | Updating affiliate links | | **Delete Affiliate Links** | Deleting affiliate links | ## Discord | Permission | Allows | | -------------------------- | -------------------------------------------------------- | | **View Discord Servers** | Viewing Discord servers | | **Create Discord Servers** | Creating Discord servers | | **Delete Discord Servers** | Deleting Discord servers | | **View Discord Links** | Viewing active Discord user links | | **Create Discord Links** | Creating Discord user links for customer inventory items | | **Delete Discord Links** | Deleting Discord user links | ## Global Commands | Permission | Allows | | -------------------------- | ------------------------- | | **View Global Commands** | Viewing global commands | | **Create Global Commands** | Creating global commands | | **Update Global Commands** | Modifying global commands | | **Delete Global Commands** | Deleting global commands | ## Custom Variables | Permission | Allows | | --------------------------- | ------------------------- | | **Read Custom Variables** | Reading custom variables | | **Create Custom Variables** | Creating custom variables | | **Update Custom Variables** | Updating custom variables | | **Delete Custom Variables** | Deleting custom variables | ## Ban | Permission | Allows | | --------------- | ------------- | | **View Bans** | Viewing bans | | **Create Bans** | Creating bans | | **Update Bans** | Updating bans | | **Delete Bans** | Deleting bans | ## Invite | Permission | Allows | | --------------------- | -------------------------------------------------------------------- | | **View Invites** | Viewing invites | | 🔴 **Manage Invites** | Sending and cancelling invitations — lets the holder bring people in | | **Kick Members** | Removing members | ## Billing | Permission | Allows | | --------------------- | ----------------------------------------------------------------- | | 🔴 **Manage Billing** | Managing billing settings — changes your plan and payment details | ## Stats | Permission | Allows | | ---------------------- | ---------------------------------------------------------------------- | | **Read Revenue Stats** | Reading revenue stats — required for [Analytics](/analytics/analytics) | *** ## Not on this list: Payouts Payouts has no permission. It is owner-only, so no combination of the above grants it. Only the store owner can open it, and that cannot be delegated. See [Account Payouts vs Store Payouts](/payments-and-payouts/account-vs-store-payouts). To check which permission gates which sidebar item, see [Why can't I see a feature?](/reference/feature-availability). To assign these permissions to someone, build a role and apply it on [Team Members](/store-settings/team-members). # Profile & General Settings Your personal PayNow account, distinct from any store you own or belong to. Your account is *you*. Stores are things your account owns or belongs to. Keeping the two separate explains most of what is otherwise confusing about permissions and payouts. *Dashboard → your account menu → General. No permission needed; this is your own account.* ## Account versus store | | Your account | A store | | ---------- | ---------------------------------------------------- | ------------------------------------- | | What it is | Your login and identity | A shop you own or work on | | How many | One | As many as you like | | Carries | Your profile, security settings, payout identity | Products, orders, customers, settings | | Roles | Roles are granted **to** your account, **per store** | Each store has its own roles | You can own one store and be a read-only helper on another with the same login. The store switcher decides which one you are looking at; each store's [Team Members](/store-settings/team-members) page controls what you can do there.
The account General page showing profile details.
## The three account pages | Page | What it covers | | -------------------------------------- | ------------------------------------------------------------------------------------------------------------- | | **General** | Your profile details. | | [**Security**](/your-account/security) | Password, two-factor authentication, passkeys. | | **Payouts** | Your payout identity. See [Account Payouts vs Store Payouts](/payments-and-payouts/account-vs-store-payouts). | ## Your account email Where PayNow contacts you about your account, including security notifications. Separate from your store's **Support Email**, where customers reach you, and **Contact Email**, where PayNow contacts you about the store. Both live in [Settings](/store-settings/store). {% hint style="warning" %} **Use an address you will keep and can still access.** Losing access to your account email makes recovery slow, and if you are a store owner it is the account your payouts are attached to. A community-shared inbox is a poor choice; this should be personal to you. {% endhint %} ## Leaving a store Leaving a store, or being removed, does not delete your account. You keep your login, security settings and payout identity, and lose access to that store. Ownership is different. It cannot be transferred by editing your own account. Contact . # Security, 2FA & Passkeys Protect the account that owns your store with a password, two-factor authentication and passkeys. Your account is the key to your store. If it is compromised, someone can change your products, issue refunds, create API keys and, if you are the owner, reach your payout settings. *Dashboard → your account menu → Security. No permission needed; these are your own settings.*
The account Security page showing password, two-factor authentication and passkey options.
## What to set up, in order ### 1. A unique password Not one you use anywhere else. A reused password that turns up in someone else's breach gets tried against every service you might hold, including this one. ### 2. Two-factor authentication With 2FA on, a stolen password alone is not enough to sign in. **Add 2FA Method** offers two choices: **Authenticator app** and **Security key (FIDO2)**. Each method you add gets a name, which you can change later with **Rename 2FA method**. {% hint style="danger" %} **If you own a store, treat 2FA as mandatory.** You are running a business that takes card payments and holds customer records. An account takeover can mean fraudulent refunds, a drained balance and a compromised customer list. {% endhint %} ### 3. A passkey PayNow supports passkeys (WebAuthn). You add one from the Two-Factor Authentication card with **Add 2FA Method → Security key (FIDO2)**, and give it a name so you can recognise it later. It is a second factor rather than a replacement for your password: you still sign in with your email and password, and the passkey stands in for an authenticator code. A passkey is bound to the real site, so a convincing fake login page cannot capture anything usable. Passwords and authenticator codes can. ### 4. Store your recovery codes somewhere safe Enabling 2FA gives you **ten recovery codes**. They are how you get back in if you lose your device, and removing a 2FA method asks for one. **Each code works once.** Ten codes means ten uses, so treat them as a finite supply rather than a password you can keep re-entering. {% hint style="warning" %} **Save recovery codes outside the device that generates your codes.** Storing them only on the phone running your authenticator means losing the phone locks you out of both at once. A password manager works, or printed and kept somewhere physically safe. Do not put them in a Discord DM to yourself. {% endhint %} ## Common threats | Threat | What it looks like | What stops it | | ----------------------- | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | **Credential stuffing** | Your reused password, from someone else's breach | A unique password | | **Phishing** | A fake PayNow login page, usually linked from Discord | Passkeys; checking the domain | | **Fake support** | Someone claiming to be PayNow staff asking for a code | Never share codes. **No PayNow employee will ever ask for your password, a 2FA code or a recovery code**, whatever their Discord name says. | | **Session theft** | Malware on your machine | 2FA, and changing your password with **Log me out of other devices** ticked | ## For teams Your security is only as good as the weakest account with access to your store. Require 2FA of anyone you invite as a [team member](/store-settings/team-members), give the narrowest [role](/store-settings/roles) that works, and remove people the day they leave. Reset any [API keys](/integrations-and-commands/api-keys) they had access to: removing someone from the team does not invalidate a key they already copied. ## If you think you have been compromised Work down this list in order. 1. **Change your password.** 2. **Enable or re-enrol 2FA**, and remove any device you do not recognise. 3. **Reset every** [**API key**](/integrations-and-commands/api-keys)**.** 4. **Check** [**Team Members**](/store-settings/team-members) for accounts you did not add. 5. **Check** [**Roles**](/store-settings/roles) for permissions you did not grant. 6. **Check** [**Payouts**](/payments-and-payouts/payouts) for changed payout details or unexpected withdrawals. People forget this step, and it is where the money is. 7. **Email** [**support@paynow.gg**](mailto:support@paynow.gg) from your own address, describing what you found. # Managing Your Subscriptions For customers, how to view, manage and cancel your PayNow subscriptions, and how refunds work. You can view, change and cancel any subscription you bought through PayNow from one place. ## Accessing your subscriptions 1. Go to [checkout.paynow.gg/subscriptions](https://checkout.paynow.gg/subscriptions). 2. Enter the **email address** you used for your purchases. 3. You will receive a **confirmation email** with a direct link. 4. Click the link to open your subscriptions dashboard. {% embed url="" %} ## Cancelling a subscription 1. Find the subscription in your dashboard. 2. Click the **Cancel (🚫)** button next to it. 3. Follow the confirmation steps. {% hint style="info" %} **Cancelling stops future payments. It does not refund payments you have already made.** {% endhint %} ## Refunds Cancelling does not refund anything you have already paid. **Ask the store you bought from first.** They can act immediately, and if the problem is the product rather than the payment they can usually fix it faster than a refund would. If they turn you down or do not reply, email with your order ID and what happened. PayNow reviews refund requests and decides them. See [Refunds and Cancellations](/for-your-players/refunds-and-cancellations). ## Cannot find your subscription? Check that you entered the email address you used at purchase. If nothing appears, try another address you own; people often buy with a personal address and search with a work one. If it is still missing, contact the store's support team. ## FAQ **Will I lose access immediately after cancelling?** No. Cancelling only stops future renewals. You keep access until the end of the billing period you have already paid for. **Can I restart a cancelled subscription?** Yes. Buy it again from the store's website. **Where do I get support?** Anything about the product itself: the store you bought from. Refunds, billing and cancellation problems: the [PayNow Discord](https://discord.gg/paynow) or . *** ## For store owners Link this page everywhere: pin it in Discord, put it in your storefront footer, include it in receipt emails. A customer who cannot find how to cancel disputes the charge with their bank instead, and a chargeback costs you the revenue and counts against your store's chargeback rate. A cancellation costs you only the next renewal. The store-side view of the same data is [Subscriptions](/orders-and-subscriptions/subscriptions). # Refunds and Cancellations For customers, how to request a refund on PayNow, who reviews it, and how to cancel a subscription. You bought something from a store that uses PayNow, and you want your money back or you want the payments to stop. Those are two different things, and only one of them needs anyone's agreement. ## Start with the store you bought from Ask the store first. It is the fastest way to sort this out, and often the only way to get what you actually wanted. The store delivers what it sells and handles problems with it directly. If your purchase went to the wrong account, never arrived, or is not working, they can usually fix it in minutes. That beats waiting on a refund you did not really want. They can also refund you themselves. Find your order ID first. It is in the receipt email PayNow sent you when you paid, and you will be asked for it. Most stores have a support channel on their Discord or a support link on their storefront. If you cannot find the receipt, search your email for the address you used at checkout. People often buy with a personal address and then search a work one. ## If the store turns you down or does not reply You can submit a refund request to PayNow. Email with your **order ID**, what you bought and when, what went wrong, and what the store said. PayNow reviews the request and decides. ## Cancel a subscription You can do this yourself, right now, without asking anyone. 1. Go to [checkout.paynow.gg/subscriptions](https://checkout.paynow.gg/subscriptions). 2. Enter the email address you used when you bought it. 3. Open the link in the confirmation email. 4. Find the subscription and click **Cancel**. {% hint style="warning" %} **Cancelling stops future payments. It does not refund what you have already paid.** If you also want the last payment back, cancel first so it cannot renew again, then request the refund separately. {% endhint %} Full instructions are in [Manage My Subscriptions](/for-your-players/manage-my-subscriptions). ## If a refund is declined Not every request is approved. If PayNow does not approve yours, the store can still choose to refund you. Ask them, and say PayNow has already looked at it. ## Common situations **I was charged twice.** Send both order IDs to PayNow. A duplicate charge from one checkout is a billing fault. **I did not mean to subscribe.** Cancel it at the link above so it cannot renew, then request a refund for the payment already taken. A subscription cannot start without a completed checkout, so there will be an order behind it. **The server removed my access after I paid.** Ask the store to restore it. If they will not, send PayNow the order ID and what happened. **I paid and got nothing.** Wait a few minutes first, since delivery can lag. See [Purchase Not Delivered](/for-your-players/purchase-not-delivered), which covers the checks worth doing before you report it. **The store has shut down.** Email with your order ID. ## How long a refund takes Once a refund is approved, the money goes back to the card or account you paid with, normally in **2 to 3 business days**. Your bank controls that last step. If PayNow shows the order as refunded and your statement still shows nothing after a week, ask your bank. Email for the **STAN code** for the refund first. It is the reference your bank needs to trace a credit they cannot otherwise find. # Purchase Not Delivered For customers, what to do when you paid for something in a game store and it did not arrive. You paid, the money left your account, and the rank or item never showed up. ## Check these first Most missing deliveries are one of three things, and all three are quicker to check than to report. 1. **Wait five minutes.** Delivery usually runs within seconds, but a busy server can lag. 2. **Rejoin the server.** Many products only apply when you next connect. Fully disconnect and come back rather than switching worlds. 3. **Check you are on the right account.** If you bought using a Steam ID, Minecraft name or Discord account, the item goes to that one. Buying on an alt and playing on your main causes most purchases that look lost. ## If it still has not arrived Contact the store you bought from first. They run the server, they can see whether the command fired, and they can send it again in one click. That is faster than anything else available to you. Give them: * your **order ID**, from the PayNow receipt email * the **account name** the item should have gone to * roughly **when** you paid The store can re-run delivery from their dashboard without charging you again. ## If the store does not respond Email with your order ID and what you have already tried. PayNow reviews refund requests, so if you want the money back rather than the item, that request goes to PayNow. See [Refunds and Cancellations](/for-your-players/refunds-and-cancellations). PayNow cannot deliver the item itself. The store delivers what it sells, and PayNow has no connection to the game server, so it cannot add a rank or change your inventory. ## Paid with cryptocurrency A crypto order that never completed is usually a transfer problem rather than a delivery one. An amount that did not match the invoice, or a transfer sent on the wrong network, cannot be refunded or recovered. [Payment Problems](/for-your-players/payment-problems) sets out where each case stands. # Payment Problems For customers, what to do when a card is declined, a crypto payment does not arrive, or checkout will not complete. Checkout failed, or the money left and the order did not appear. What to do depends on how you paid. ## Your card was declined PayNow does not decide this. Your bank does, and it does not tell us why. The two common causes: 1. **You did not finish the bank's confirmation.** Many cards send a prompt to your banking app or by text. Close nothing until it completes and the checkout returns. 2. **Your bank refused it.** New merchant, unusual amount, or a country it does not expect. Try the payment again and complete any prompt your bank sends. If it fails twice, call your bank or use a different payment method. Repeating a declined card usually keeps failing. A declined payment takes no money. If you see a charge for one, it is a pending authorisation and it drops off on its own, normally within a few working days. ## Your subscription payment failed If a subscription that was working suddenly stops, the usual cause is the card being replaced, expiring, or the recurring approval being withdrawn. Cancelling a payment method at your bank also stops the subscription. Update or re-purchase from the store you bought from. See [Manage My Subscriptions](/for-your-players/manage-my-subscriptions). ## You paid with cryptocurrency Crypto is the one payment method where a mistake cannot be undone. {% hint style="danger" %} **Send the exact amount the invoice asks for, on the exact network it names.** Send too little, too much, or on a different chain, and the payment cannot be refunded or returned. There is no recovery process for it. Check both figures before you confirm the transfer. {% endhint %} | What happened | Where it stands | | ------------------------------ | -------------------------------------------------------------------- | | Sent less than the invoice | The order will not complete, and the amount sent cannot be refunded. | | Sent more than the invoice | The difference cannot be returned. | | Sent on the wrong network | The funds cannot be recovered. | | Payment says **blocked** | Held by the crypto payment provider for review. | | Crypto not offered at checkout | Not available in every region. Use another method. | A blocked payment is held by the payment provider that handles crypto, under their own review process. That review is theirs, not PayNow's, and PayNow cannot decide it or speed it up. If the provider releases the payment your order completes, and if they refund it you will be emailed about it directly. If your order did complete and the item never arrived, that is a delivery problem rather than a payment one. See [Purchase Not Delivered](/for-your-players/purchase-not-delivered). ## The checkout page will not load or finish Try a private window with extensions disabled. Ad blockers and strict tracking protection are the most frequent cause of a checkout that hangs or shows an empty box. If it still fails, tell the store you are buying from. A checkout broken for everyone is usually something in their storefront template, and only they can fix it. ## You were charged but have no order Search your email for the address you used at checkout, not the one you normally use. The receipt has the order ID on it. If nothing arrives, email with the amount, the date, and the last four digits of the card. PayNow can find the payment and tell you which store took it. See [Refunds and Cancellations](/for-your-players/refunds-and-cancellations) for what happens next. # Why can't I see a feature? Why a feature you read about isn't in your dashboard, and what each plan includes. If a guide describes something you can't find, one of two things is true. ## 1. Your plan doesn't include it Everything in a lower plan is included in the ones above it. | Plan | Platform fee | Monthly sales limit | Adds | | -------------- | ------------ | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | **Free** | 3.5% | Up to $2,000 | Chargeback protection, headless API, custom templates, worldwide payments, basic statistics | | **Pro** | 3% | Up to $5,000 | [Custom domain](/your-webstore/webstore), [detailed statistics](/analytics/analytics), [affiliate links](/marketing/affiliate-links) | | **Business** | 2.5% | Unlimited | [Custom checkout branding](/your-webstore/branding), [regional pricing](/products/creating-a-product#regional-pricing) | | **Enterprise** | Custom | Custom | Talk to PayNow | If a feature isn't named in that table, it's in Free. The paid plans add what's listed and nothing else. Your current plan is under **Billing → Tier Details**. See [Billing](/payments-and-payouts/billing) to change it. ## 2. Your role doesn't allow it Every sidebar item needs a read permission. Without it, the item isn't shown at all. Ask an administrator to check your role against the [Permissions Reference](/store-settings/permissions).
Which permission each sidebar item needs | Sidebar item | Permission | | ------------------- | ------------------------- | | Analytics | `stats_revenue_read` | | Orders | `order_read` | | Subscriptions | `subscription_read` | | Customers | `customer_read` | | Products | `product_read` | | Trials | `trial_read` | | Game Servers | `gameserver_read` | | Discord Servers | `discord_server_read` | | API Keys | `apikey_read` | | Webhooks | `webhook_read` | | Webstore | `webstore_read` | | Tags | `tag_read` | | Navlinks | `tag_read` | | Branding | `branding_update` | | Sales | `sale_read` | | Coupons | `coupon_read` | | Gift Cards | `giftcard_read` | | Affiliate Links | `affiliate_link_read` | | Upselling | `upsell_read` | | Abandoned Checkouts | `abandoned_checkout_read` | | Purchase Follow-Ups | `purchase_follow_up_read` | | Members | `invite_manage` | | Roles | `role_read` | | Bans | `ban_read` | | Billing | `billing_manage` | | Settings | `store_update` | | Global Commands | `global_command_read` | | Custom Variables | `custom_variable_read` |
{% hint style="warning" %} **Payouts is the exception.** Billing → Payouts is **owner-only**. No permission controls it, so no role can be granted access, not even a full Administrator. Only the store owner can open it. See [Account Payouts vs Store Payouts](/payments-and-payouts/account-vs-store-payouts). {% endhint %} ## Still missing? Check the store switcher in the top bar. Plans and roles are both **per store**, so you may be an Administrator on one and read-only on another.
The store switcher in the top bar, expanded to show two stores.

Everything on this page applies per store, so check which one you're in.

# Is It Down? How to tell whether a problem is on your side, your host's, or PayNow's, and what to report. Something is failing and you need to know whose problem it is before you can fix it. The fault line is usually easy to find. ## Storefronts showing an internal error An internal error across your storefront, or payment and product pages loading intermittently, is almost always a platform-side incident rather than anything in your store or template. These are worked on as they happen. Check the announcements channel in the [PayNow Discord](https://discord.gg/paynow) before debugging your own store. If nothing is posted, report it there with your store ID and roughly when it started. Don't start editing your template to fix an error you didn't cause. ## Your server says it cannot reach PayNow The plugin only makes outgoing requests. There is no inbound connection and no port to forward, so a server that suddenly cannot reach PayNow after working fine is almost always a network problem at your host. A DNS resolution failure is the clearest case: your machine could not look up the address at all, which is your host's resolver, not PayNow. Ask your host first. Occasional failed requests are different and normal. The plugin retries them on its own, so an intermittent `failed to handle pending commands` in the console needs no action. See [Game Servers](/integrations-and-commands/game-servers#when-commands-do-not-run). ## Rate limited at checkout Clicking add-to-cart rapidly can trip Cloudflare's rate limiting on the checkout. It clears on its own after a short wait. If a customer reports it, have them pause a minute and try again rather than keep retrying. ## What to include in a report * Your **store ID** * What failed, and the exact error text if there was any * When it started, and whether it is constant or intermittent * One **order ID** if a specific purchase is affected # Glossary PayNow terms, and the distinctions that cause the most confusion. ## Pairs that get confused Five pairs of terms that look similar and are not. Most support tickets trace back to one of these. | | | | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Sales** vs **Net** vs **Balance** | Sales is gross, what customers paid. Net is after tax and fees. Balance is settled net you can withdraw. → [Transactions](/payments-and-payouts/transactions) | | **Billing** vs **Payouts** | Billing is what PayNow charges *you*. Payouts is what PayNow pays *you*. | | **Tags** vs **Tier Groups** | Tags group products for display. Tier groups make upgrades charge only the difference. | | **Inventory** vs **Orders** | Inventory is what a customer currently has access to. Orders is every transaction they made. | | **Refund** vs **Chargeback** | A refund is you returning money. A chargeback is the customer's bank taking it, plus a fee, plus a mark against your store. | *** ## A–Z **Adaptive Currency** shows and charges prices in the customer's local currency. On by default, free on every plan, and PayNow carries the FX risk. → [Adaptive Currency](/store-settings/adaptive-currency) **Affiliate link** is a tracked code or URL that pays a partner commission on sales they refer. → [Affiliate Links](/marketing/affiliate-links) **Chargeback** is a customer disputing a payment with their bank rather than asking you. It costs you the revenue and a fee. → [Orders](/orders-and-subscriptions/orders) **Command placeholder** is a token like `{customer.steam.id}` that PayNow swaps for a real value before your server runs the command. → [Commands & Placeholders](/integrations-and-commands/commands) **Custom variable** is a question asked at checkout (colour, name, quantity) whose answer feeds into your commands. → [Custom Variables](/integrations-and-commands/custom-variables) **Deliverable action** is what a product does on purchase: run a command, assign a Discord role, issue a gift card, grant a file. → [Creating a Product](/products/creating-a-product) **Gateway fee** is charged by the payment processor for handling the card. **Global command** runs on an event for every product, not just one. → [Global Commands](/integrations-and-commands/global-commands) **Headless API** is the integration type where you build your own storefront and PayNow handles payment and delivery. → [Settings](/store-settings/store) **Inventory** is what a customer currently has access to, active or expired. → [Managing Customers](/customers/managing-customers) **Merchant of record** means PayNow is the legal seller, so PayNow handles tax collection, remittance and fraud liability rather than you. **Metadata** is hidden key-value data on a product or customer, surfaced in webhooks and the API. Never shown to customers. **Module** is a dynamic storefront component such as a payment goal, top customers or recent payments. → [Webstore](/your-webstore/webstore) **MRR** is monthly recurring revenue, shown per customer and across the store. → [Analytics](/analytics/analytics) **Navlink** is a navigation bar button pointing at a tag. → [Navlinks](/your-webstore/navlinks) **On Expiry Action** is what happens when a package expires, and also what happens when you **revoke** one by hand, since revoking runs the expiry path. **Without one, nothing happens on expiry, and a non-expiring package cannot be revoked at all.** → [Packages FAQ](/products/revoking-and-expiry) **Owner-only** means restricted to the store owner and not grantable by any role. Payouts is the notable example. → [Account Payouts vs Store Payouts](/payments-and-payouts/account-vs-store-payouts) **Payment descriptor** is the text a customer sees on their bank statement. It comes from your **Store Name**, and an unrecognisable one causes chargebacks. → [Settings](/store-settings/store) **Payout account** is where your money goes. It belongs to an **account**, not a store, so one account covers every store it owns. → [Account Payouts vs Store Payouts](/payments-and-payouts/account-vs-store-payouts) **Platform fee** is PayNow's percentage of each sale: 3.5% on Free, 3% on Pro, 2.5% on Business. → [Billing](/payments-and-payouts/billing) **Presentment fields** are the `presentment_` fields on orders and subscriptions, holding the amount in the currency the customer actually paid. → [Adaptive Currency](/store-settings/adaptive-currency) **Settlement** is funds becoming withdrawable. **Settles In** on [Transactions](/payments-and-payouts/transactions) shows when. **Slug** is the URL-friendly identifier for a store, product or tag. Changing one breaks every link already shared. **Tier group** is a ranked ladder of products where upgrades charge only the difference. **Rank comes from the order on the Products page, not from price.** → [Tier Groups](/products/tier-groups) **Tipalti** is PayNow's payments partner, which handles payout onboarding. → [Setting Up Your Payout Account](/getting-started/payout-account) **Trial** is a free period before a subscription starts billing. Subscription products only. → [Trials](/orders-and-subscriptions/trials) **Twig** is the templating language used by hosted webstore templates. → [Editing Template Files](/your-webstore/editing-template-files) **Upsell** is an additional product offered during checkout. → [Upselling](/marketing/upselling) **Webhook** is an event notification sent to Discord as an embed, or to your own endpoint as JSON. → [Webhooks](/integrations-and-commands/webhooks)