APP user guide

You don't have to learn every menu before you start. Get one panel, one plan, one payment method and your email sender working first. Once that path works, adding more plans feels familiar.

Your invitation or signup

Use your setup or verification email to finish registration and choose your own password. An owner-created invitation lasts 24 hours; if it expires, ask APP support for a fresh link. Sign in at app.autoprovisionpro.com/login and check the selected workspace before making changes.

What your access includes

Your plan or complimentary test grant controls feature access and panel capacity. Check Billing > APP subscription for your current access. A grant does not supply provider accounts, panel credits, email credentials or unfinished future modules. Its expiry is shown in your account, not in this guide.

1. Open Overview > Setup. Work through the saved setup steps, not just the dashboard totals.
2. Keep your own panel login, email sender and payment account ready. You enter those privately in their connection forms.
3. For your first test, use a clearly named sample plan and your own test recipient. Agree on any real charge or credit use before proceeding.

Think of the menu as a workday: set up the business, find the customer, sell the service, look after it, then handle billing and support.

Small controls that save time

The workspace selector near the logo changes which business you are operating. It is not a customer selector. Use the sidebar search to find a tool and the top search to find records. Customer, Order and Services shortcuts take you to the main workflow. Hover an unlabeled top-bar icon for its description; the bell opens alerts. The appearance control changes light/dark/system mode.

This is the shortest route from a connected panel to something a buyer can actually purchase. Don't start by decorating the storefront and hope the plans appear later.

1. Go to Services > Panel connections. Save your panel, run the connection test, then discover its catalog. You need named packages and channel groups before building an offer.
2. Open Overview > Add plans to website. Choose that tested panel. Select the package or variants you intend to sell from the discovered catalog.
3. Choose the service term, connection count and locked channel selection. Give each offer a customer-friendly name and set your selling price and currency. Panel credit cost is not your selling price.
4. Save the offers. Review them in Sales > Plans & packages; keep unfinished ones as drafts and publish the ones you want visible.
5. Open Billing > Payment methods and configure your own gateway. Set up and test your sender under Marketing > Email & campaigns.
6. Open Store > Storefront designer. Save your branding, preview the buyer view and publish the storefront as well as the offer.
7. Open the public plan link. Check name, term, connections, channels, price and payment method before attempting a purchase.

A plan is missing?

Check both publication switches, the selected workspace, any search/category filter and the plan's panel mapping. A saved draft is not a published product.

A panel connection lets APP work with your reseller account on that panel. It does not give you new panel permissions or credits.

1. Choose the correct panel brand and connector type. NXT, XUI and Xtream UI are different integrations; similar-looking login screens do not make them interchangeable.
2. Enter a recognizable connection name, such as K2. Enter the reseller administration URL requested by the form, not a playlist or player URL.
3. Enter your own reseller login or API credentials. If the provider requires API access to be enabled, arrange that with the provider first.
4. Save the connection and run its connection test. Read the result: login failure, insufficient permission and unavailable host are different problems.
5. Discover the catalog so APP can load packages and channel groups by name. Review the discovered data before making an offer.

Cards, list and tools

Use the card/list toggle to scan saved connections the way you prefer. Manage opens the selected connection; Tools & catalog exposes testing, discovery and supported login tools. Check the actual URL and connection name when two entries look alike.

What the badges mean

Verified identifies a more thoroughly supported connector; Assisted means it still needs extra care; Unverified is not a promise of a working lifecycle. NXT, XUI and Xtream UI are the first-release priorities. Treat other providers according to their current badge and test results.

A package tells the panel what it is allowed to create. A channel group tells it what the customer can access. A saved lineup is your reusable selection of those groups.

1. Run discovery for the selected connection. Look for the named package you intend to sell and the groups you actually want included.
2. In Sales > Plans & packages, choose that panel and package. Pick channel groups by name rather than typing IDs.
3. If you will reuse the selection, save it as a clearly named group template/lineup, such as Standard lineup - K2.
4. Use the saved lineup on later offers for that same panel. For another panel, create its own mapping; IDs are not portable.
5. After the upstream panel changes packages or groups, run discovery again and review affected offers and service-default mappings.

Why an old selection can stop working

Discovery saves a catalog snapshot. A package may later be removed, permissions may change, or the panel may replace a group ID. Refreshing the catalog makes new choices visible; it does not justify silently substituting all channels.

If the expected trial or package is absent

Check the connection type and reseller permissions, then refresh discovery. If it is still missing, contact APP support with the connection name and package name. Do not guess a remote ID or use a package from another server.

Some buttons still use the word template. Here, an offer/template is the sellable plan: it combines a panel package with your locked service settings and retail price.

1. Start from quick setup for a discovered package, or use the manual editor when you need one specific plan.
2. Enter a clear plan name. Choose its panel connection and the matching named panel package. Pick a saved lineup or select the allowed groups.
3. Set duration in days and the number of connections/devices. Check that the panel supports those values; a field accepting a number does not prove the panel will honor it.
4. Set selling price and currency. Choose One-time payment or Automatic renewal; if recurring, review the month/year interval fields.
5. Add an optional image, storefront category and short description. Explain what the buyer gets without exposing panel administration details.
6. Save, review the public plan preview and publish only after checking the full configuration.

Example, not a price recommendation

A plan might be called "Standard - 30 days - 1 connection" and use your K2 package plus its saved Standard lineup. You set the retail price. The example does not assume that every panel uses exactly 30 days for a calendar month.

Use the compact list for day-to-day work. Group by panel when you want to compare one server's products, or by category when you are organizing the storefront.

1. Use the search and status filter first. Switch between List, By panel and By category as needed. Check the panel name before editing similar plans.
2. Choose Edit to change the plan. Use Copy / Duplicate & edit to start a new draft without rewriting the original.
3. When moving a copied plan to another panel, select that panel's real package and its channel groups. Recheck term, connections, price and lock settings.
4. Drag the ordering handle where supported, or use the up/down controls. Review the storefront afterward to confirm the intended order.
5. Publish to make a ready plan available, or unpublish to stop new purchases. Archive a plan you want out of the normal working list.

Delete versus archive

Delete is permanent and may be blocked when a record is in use. Archive is for keeping a record without advertising it. Neither action is a substitute for terminating an active customer line. Existing orders keep their historical purchase details.

Categories are not panel connections

A category is a storefront grouping label. Panel grouping follows the connected server; uncategorized plans can fall back to panel grouping. Choose categories intentionally rather than renaming a panel to rearrange products.

Service defaults save the settings you repeat, such as a term, three connections and a standard lineup. They do not replace the destination panel package or retail price.

1. First save the channel lineup you want for each panel in the plan editor. Each panel needs its own real group selection.
2. Open Service defaults and create a named default, such as "Long term / 3 connections". Enter duration in days, connection count and login type.
3. For each connected panel, choose its matching saved channel-group template. The same business idea can map to different upstream group IDs.
4. Save the default. When creating an order, select the destination product/panel package first, then apply this service default.
5. To make it convenient for a particular customer, open their Overview tab and save it as their default subscription/service setup.

What carries over

The default can supply duration, connections, username/password versus MAG login type, and the mapped lineup. Price and panel package still come from the chosen destination product. A missing or stale mapping should be fixed, not replaced with all channels.

MAG services

Choose MAG only for a supported panel flow and enter the customer's MAC address when the order form requires it. A device MAC is not a panel account ID.

Decide which kind of trial you mean before you create it. A free trial and a small paid checkout test are different flows.

1. Connect and discover the panel first. Select an actual trial package/mode from that panel's catalog rather than inventing a duration.
2. Create the trial offer with the correct free or paid-trial option. Review the term; the app limits trial offers to at most seven days, and the panel can impose a shorter limit.
3. For a manual trial, open Sales > New order, use a valid customer email and select the trial offer. Check the target panel before creating.
4. After creation, verify the panel account ID, active state and actual expiry on the service record. Confirm customer delivery if you supplied an email.
5. For a paid trial, test the real checkout path only with approval for the stated amount and any panel credit use.

The directory is intentionally a quick view: name first, service second. Open the person to see email, invoices, tickets and the details that do not belong in a crowded list.

1. Choose Add customer. Enter the person's name or useful display label and a valid, unique email. New customer accounts and manual orders require email.
2. Choose the appropriate contact type/source, then add useful contact details, preferred device and private notes. Save the customer.
3. Open the saved profile. Check the email carefully before creating or delivering any service.
4. Use the directory search to find them later. Click their name/Open rather than trying to manage a service from the bird's-eye list.

Email does not equal a portal login

Saving a contact email identifies the customer and gives billing/delivery a recipient. It does not by itself create a sign-in password, send a portal invitation or prove that a portal account exists. Use only the portal/login tools actually shown for that customer.

Importing a CSV

Use Import from the customer directory. Start with a small clean CSV: email, first_name, last_name and display_name are useful columns; name/label can supply the display name. Optional fields include status, telegram, discord, whatsapp, preferred_device, referral_source and notes. Choose the file and press Import CSV; inspect the imported/skipped counts.

Use the tabs to answer one question at a time. There is no need to open several unrelated menus to understand the account.

Keep the recipient correct

Update the email in Overview and save it. The current customer email is used for eligible reminder delivery, including linked older orders. That correction does not automatically create a customer portal login.

Groups, merging and deletion

Assign a customer group to organize contacts. If merge is offered, carefully choose the surviving customer: linked history moves and the duplicate is removed. Delete customer is not archive and is not a remote panel termination; the app protects unsafe cases and can retain/unlink transaction history. Wallet data can be affected. Review balances and linked services before confirming.

There are three different logins: your APP reseller login, the buyer's portal login and their service-player credentials. Help the customer use the right one.

1. A new buyer opens a published plan on your storefront. In Customer account, they enter their name/email and choose and confirm a customer account password. An existing buyer chooses Sign in first.
2. They review the optional marketing choice and promo code. Where a balance is available, Apply store credit can use it before charging the payment method.
3. For Service login, they choose only an offered supported type. Generate simple service credentials for me supplies a short compatible login, or they can use the allowed manual fields. MAG requires the device MAC address.
4. They complete the intended checkout or eligible trial claim. After payment verification and activation, Service details shows the delivered access and expiry.
5. Later they use your storefront's Sign in link with their portal email/password. The portal shows orders, service details, receipts and support tickets.
6. For eligible recurring orders, use the shown Stripe Pay bill or update payment method or Manage PayPal billing control. For an eligible trial upgrade, use Continue with this account.

Adding is not necessarily switching

The portal's Change or add a plan opens plan choices. Buying a different offer is not a promise to replace or migrate the existing remote line. Use the controlled service/upgrade path for that intention.

Welcome email and customer guide

A buyer who creates their own portal password at first checkout gets a welcome email from your configured sender, with your branding and a link to your customer guide. This confirms the website account, not service activation. Service-ready emails also include that guide. No welcome is sent just because you save a contact or use Login as customer. Without a configured sender, the failure appears in email history; APP does not substitute its own sender.

A manual order is for a sale or setup you are handling yourself. Creating it can queue the panel action immediately; it is not just a harmless draft invoice.

1. Open the customer first if you already have them, or enter their name/label and valid delivery email in New order. Choose the order source and add a useful internal note.
2. Select the destination product / panel package. Check the connection name and exact package. Apply a reusable service default only if you want its term, connections and lineup.
3. Supply a MAC address for a MAG flow when required. Optional username/password fields are for supported creation; otherwise the connector generates compatible credentials.
4. Use Payment received only if you really received the money. This checkbox records a fact; it does not charge a card or check a bank transfer.
5. Review the full target and create the order. Provisioning is queued automatically. Watch the existing order rather than clicking Create again.
6. Open the customer's Services tab. Look for active state, the remote account ID and confirmed expiry. Then verify delivery and email history.

If it waits or fails

The recent-orders area can show Provision now or Retry provisioning. First check the queue and the panel itself. If the line already exists, do not repeat creation blindly; report the existing ID and order to support.

This is the closest thing to a service control desk. Payment history lives with the order; panel actions belong to the individual service.

Which ID matters?

The Panel account ID is the line ID on the upstream panel. APP's own service ID identifies the record inside this application. They are different. Keep the panel ID correct so a future renewal targets the existing line.

When a button is absent

Actions depend on state, connector capability and permissions. For example, a failed create and an active line should not show the same options. Do not infer that termination or renewal is supported by every connector just because the general UI has those concepts.

Use this when you have already created the customer's destination account and want future billing/actions to use it. You do not need an automatic migration to relink an existing line.

1. Open the destination panel privately. Confirm the customer's new account exists and record its real account ID, username, password and expiry.
2. In APP, choose the correct customer and service. Make sure no provisioning or renewal job is currently running for it.
3. Choose Edit service. Select the tested destination panel/server and a matching destination product/template.
4. Enter the destination Panel account ID and updated service username. Enter Replace service password if it changed; blank keeps the saved password.
5. Set the recorded panel expiry if needed, add the required internal change reason, and save the active service record.
6. Reopen it and verify all four bindings: panel, destination product, remote ID and credentials. Inspect any existing unpaid invoice before asking the customer to pay.

What the next renewal should do

An eligible paid renewal uses the service's current destination binding and current credentials to renew that existing account. APP should not create another line simply because you changed from K1 to K2. Conflicting/stale invoices or an account that cannot be verified need review, not a success message.

There are three separate tasks: tell the customer what is due, verify payment, then extend the correct line. A due date alone is not permission to take money.

Normal manual-payment services

The reviewed configuration runs the daily service-billing job at 9:00 AM America/Chicago. Eligible active paid services using manual renewal billing get a cycle-specific invoice within the seven-day due window. Reminder points are 7, 3, 1 and 0 days before due. Delivery still depends on your enabled, tested sender and a valid current customer email.

1. Check the service expiry, chosen product and customer email before the cycle is due. Set up your sender early, not on the due day.
2. Open the renewal invoice or the Renewals queue. Confirm the destination panel, term, amount and currency.
3. Have the customer pay through the offered verified payment path, or confirm an actual manual transfer using the pending-payment tools.
4. After verification, watch the renewal job. Confirm it extended the same current panel account ID and recorded the panel's new expiry.
5. Check email history and the actual recipient inbox. A queued message is not a received reminder.

Autopay and trials are different

Processor-managed recurring services use their subscription/payment-event path; do not manually charge again just because you also see an invoice screen. Trial conversion has separate eligibility and is not automatic billing consent. Renew manually is an immediate admin action, not a scheduled-payment test.

Invoices answer what the customer owes or paid. They are separate from APP's monthly fee to you as a reseller.

1. Open Invoices and search for the customer, invoice, product or provider reference. Narrow the list by payment state, provider or date range.
2. Open the relevant record. View/pay on a renewal leads to the payable renewal path; a paid record can expose the receipt.
3. Before sending a payment link, verify the customer, amount, currency and service. If you recently relinked that service, review outstanding old invoices.
4. After payment, check payment state and then the service outcome. Paid and provisioned are related, but they are not the same status.

How to create the right record

For a new line, use Sales > New order or the buyer checkout. For an existing line, use customer Services > Invoice renewal when available. This is not a full WHMCS arbitrary line-item invoice editor; do not expect an empty invoice by itself to create or import a line.

An unavailable link

Some unpaid/non-renewal order records do not offer a payment link and may show Not available. That is different from a renewal invoice with a supported pay action. Use the intended service workflow instead of inventing a URL.

When something stalls, inspect the existing record. Repeating checkout or creating another manual order can turn one problem into two lines.

1. Start in Today's work for an action list, or open the appropriate order/service queue.
2. Select the affected record and read its latest failure/activity. Check panel connection health separately from payment health.
3. Correct the underlying cause first. Use the offered retry only after confirming the operation is safe to repeat.
4. If you cannot tell whether a remote create/renew succeeded, stop and send APP support the order/service IDs, connection name, time and error text.

These are the accounts that receive your customers' money. They are not the APP owner's account used for your platform subscription.

1. Pick the gateway you want to use. Your plan or test grant controls available choices; a basic plan has one included choice, not a forced default.
2. Choose Configure or the supported Connect action. Unlocking a feature does not configure a provider account.
3. Enter your own credentials in the private form and review live versus sandbox/test mode. Do not paste secrets into support tickets or this handbook.
4. Configure the exact callback/webhook values shown for this workspace and save/activate the connection.
5. Run an approved checkout test and verify the payment event, order, panel result and delivery before considering that gateway proven.

Why not every card has OAuth

OAuth is a provider-supported authorization flow, and some Connect buttons also depend on APP platform configuration. A missing or disabled Connect button is not fixed by logging into the owner's account. Direct credential setup can be the intended option. Interac and Wise here are manual-payment methods, not OAuth gateways.

One gateway, many panels

Your payment method serves your workspace's plans. You do not need a separate Stripe key for each service panel. Panel credentials and payment credentials solve different problems.

Use your own Stripe business account for customer checkout. Choose the existing-account connection path when that is your intention; new-account onboarding is a different path.

1. If Connect existing Stripe is available, follow its authorization screen and confirm the business/account before approving. Return to APP and check the saved connection.
2. For direct setup, enter the form's publishable key, secret/restricted key and webhook signing secret. Keep keys scoped appropriately; enter them only in the private gateway form.
3. Keep the environment consistent: test keys with test events, live keys with live events. A sandbox receipt does not prove that live mode is configured.
4. Use the webhook URL displayed for this workspace. Create/configure the provider destination with the required events shown by APP, then save its signing secret in APP.
5. Save/activate the gateway. Inspect the configured card and any error rather than repeatedly starting OAuth.
6. Use a clearly labeled approved test offer. Once checkout completes, inspect the verified order and actual service account/expiry; confirm customer delivery.

If this is also the platform owner's account

A platform cannot necessarily OAuth-connect to itself. The owner's workspace may need its supported direct-key path. Other resellers must still use their own accounts; do not distribute platform billing credentials.

Use the fields in APP for the provider you selected. Do not assume a personal payment handle is interchangeable with a business integration.

PayPal

Use Connect if the supported partner flow is enabled, or the direct REST-app form. The current direct form asks for Client ID, Client secret, Webhook ID and environment. Use the same live/sandbox environment for the app and its webhook. A reseller can use their own direct app; no need to share the APP owner's personal PayPal identity or account.

Square

Use the supported authorization flow if available, or enter the access token, location ID and webhook signature key requested by the form. Confirm that the location belongs to your business and that its event configuration matches the environment.

Cash App Pay

This gateway is implemented through a supported Square application. The APP form uses Square-style access, location and webhook credentials. It is not a free-form personal $cashtag transfer or a screenshot-based automatic verification tool.

1. Configure the gateway privately, copy the workspace callback details shown by APP, then save/activate it.
2. Open a published plan and confirm the intended method appears at checkout.
3. Run an approved payment test. Verify the APP payment record, panel outcome and delivery before advertising the method as working.

The two crypto options have different connection forms. Keep the provider settings aligned with the APP gateway you actually selected.

NOWPayments

Enter the API key and IPN secret requested by APP. Configure the callback/IPN URL shown for this workspace. The callback is how APP learns a payment's verified state; merely creating a crypto invoice is not a fulfilled order.

BTCPay Server

Enter your server URL, store ID, API key and webhook secret. The server and store must be yours or an authorized connection. Follow the permissions/event requirements displayed during setup and verify the saved store connection.

1. Choose the gateway, enter credentials privately and save the matching provider callback configuration.
2. Save/activate it in APP and check configuration errors before exposing a public plan.
3. For an approved test, track the provider payment state and the corresponding APP order. Do not manually mark paid while a provider confirmation is still pending.
4. Once APP verifies payment, confirm the provisioning or renewal outcome on the panel and then customer delivery.

If the amount or status does not match

Keep the order in review and send APP support the provider reference, amount, currency, time and error. Do not change an invoice amount after checkout to force a match. Network/provider payment timing can differ from a card payment.

These methods rely on you confirming an actual transfer. They are useful, but they cannot automatically know that a customer's bank payment arrived.

Interac e-Transfer

Configure the recipient email/name, instructions and the CAD conversion value if your form uses it. Add the optional question/answer only when it is appropriate for your transfer setup. Check the checkout instructions for accuracy before publishing.

Wise

Configure the payment link if you use one, plus display name and transfer instructions. The buyer needs a clear amount, currency and reference. A Wise link does not turn this APP integration into an automatic bank-feed connection.

1. Save/activate the manual method and preview exactly what a buyer will see.
2. When a buyer submits a payment claim, inspect the pending payment record. Check your actual receiving account independently.
3. Match recipient, amount, currency and reference to the order. If it is wrong or missing, leave it unverified and contact the buyer.
4. Use Mark paid only after the funds are genuinely confirmed. APP can then queue the supported fulfillment action.
5. Check the resulting line or renewal and delivery, just as you would for an online gateway.

Need automatic collection?

Use a supported verified online gateway. Do not relabel a manual bank transfer as OAuth or automatic payment processing.

Your customers should recognize the sender. APP platform-account mail and your customer billing/service mail are separate.

1. Expand Sender settings. Choose a provider preset if useful, or Manual. A preset fills connection defaults; it does not create an email-provider account.
2. Under Step 1 > Email provider, choose your provider. APP fills in its host, port and security. For your own domain mailbox, choose Other provider / my domain mailbox and copy the outgoing SMTP details from your mailbox host.
3. Enter your Sending email address and the provider-specific secret. Gmail needs your address and a Google app password, not your normal password or an OAuth sign-in. Mailgun needs its SMTP login and SMTP password; Postmark needs its Server API token once. Resend, SendGrid and Mailchimp Transactional use their sending API keys. Verify your sender/domain with the provider. Open Advanced settings only to change your sender name, Reply-to or technical details.
4. Leave Enable customer email on and press Save & send test to me. It saves the settings and sends only to your signed-in APP email. Provider accepted means the server accepted it, not that it reached your inbox: check inbox, spam and provider logs. A failed test explains what to fix and appears in delivery history. Demo tests are explicitly simulated, with no real email sent.
5. Resolve any provider rejection or authentication problem before relying on receipts, service-ready mail or renewal reminders.
6. Verify the current customer email in their Overview tab. Check their Emails tab after a real service message is attempted.

Changing a saved password

The form can keep a saved secret when you leave its replacement blank. Only enter a replacement when you intend to change it. Do not include it in a support screenshot.

If no message arrives

Look for a failed/queued delivery in APP, then check provider logs, sender verification, SMTP permissions, spam and the recipient spelling. Accepted by SMTP means the provider accepted the message, not that the recipient opened or even received it.

Use campaigns for messages you choose to send. Automatic service and billing notices have their own triggers; do not recreate them as promotions.

1. Set up and test Sender settings first. Then open the message composer.
2. Choose the truthful Message type: a service notice for necessary service information, or product news/promotion for marketing.
3. Choose the available audience: all eligible customers or one customer. For an individual message, verify the recipient email.
4. Write a specific subject and a clear body. Include what changed, what the customer needs to do and where to get help. Never include panel-administration passwords.
5. Save a draft if it is not ready. Otherwise queue it, or use the Send at option and review the scheduled time before scheduling.
6. Check campaign history and delivery results. For an individual customer, inspect their Emails tab as well.

A useful message sounds like this

"Your service is due on [date]. Open your renewal invoice to keep the same account active. If you already paid and it has not updated, reply with your invoice number." Replace the date/reference with correct details; do not promise an extension before the panel confirms it.

Respect preferences

Promotions should go only to eligible recipients under the app's marketing preferences. Calling an advertisement a service notice is not a way around an opt-out.

Wallet credit is stored value in your workspace. It is not a panel credit balance, and adding money is not itself a service renewal.

1. Configure your supported Stripe customer-payment connection and verify it. The included wallet top-up feature depends on its payment path.
2. For a customer who has access to the portal, have them use the wallet/top-up control and complete the secure checkout.
3. Check that a verified successful payment creates the correct ledger credit for that customer. A return to the portal alone should not credit the balance.
4. Open the customer's Wallet tab to review their balance and ledger. Confirm any later credit usage against the associated supported purchase/payment flow.
5. If you make an allowed manual adjustment, enter the correct positive/negative amount and an internal reason. Recheck the ledger after saving.

What early funds do not mean

A positive wallet balance does not by itself prove that a renewal invoice was paid or that a panel line was extended. Follow the invoice/payment/service trail. Do not assume every future checkout or renewal has a wallet action unless the current screen offers it.

Corrections need an audit trail

Do not create a second top-up because an event appears delayed. Compare the provider payment reference with the ledger first. Report a verified charge with no matching credit, or duplicate credit, to APP support.

These tools organize offers or track sales activity. They do not change the remote panel account configuration.

Put plans into categories

Open Categories, enter a useful storefront label and create it. Edit a plan under Plans & packages and assign that category. Review By category and the public storefront. Renaming a category does not unlock a plan's package or channel mapping.

Set up a promo code

Open Promo codes and use its create form. Enter the code and the discount/limits the current form supports. Check currency, validity dates and any redemption restrictions before saving. Test an eligible checkout and an ineligible one; the final payable amount should match your intended discount. Existing paid orders are not repriced just because a new code exists.

Use customer groups

Open Customers > Customer groups, create the organizational group, then assign it on a customer's Overview tab. A CRM group is not a channel group or storefront category. It does not by itself change a customer's plan or send a campaign.

Read referrals

Marketing > Referrals shows the current basic referral codes/activity and leading referrers. Use it to identify attribution. Do not promise automatic cash commissions, multi-level rewards or a loyalty program: the enhanced Referral Plus and rewards tools are future modules.

Start with one code and test the rules. A discount should change the buyer's price, not their locked package, connections or channel lineup.

1. Choose Single code and enter the Code, such as a clearly labeled sample SAVE10.
2. Choose Percentage or Fixed amount. Enter Percent off or Amount off. Check the final payable amount and currency on the intended plan.
3. Set a Total usage limit if needed; blank allows unlimited total uses. Set Uses per customer so one buyer cannot redeem more times than intended.
4. Choose Discount application: One-time or Recurring (first charge). The recurring label here does not promise a permanent discount on every future payment.
5. Choose an Expiry date if wanted. Select Specific plans to restrict it, or leave that selection empty to allow all plans. Set New customers only when that is your intention.
6. Check Active and press Create code. Test both an eligible checkout and a checkout that should be rejected by your rules.
7. For a campaign batch, use Bulk generate, choose a prefix and number of codes (up to 50), apply the same rule settings and press Generate codes.

After creation

The list shows usage and expiry. Redemptions count when payment completes, not merely when a buyer types the code. Use Activate/Deactivate to control future acceptance. Delete removes the code permanently; it is not an edit to an old paid invoice.

The storefront is your business's buyer-facing page. Your workspace theme and the storefront's saved design are related preferences, not the same screen.

1. Set your business name, logo and brand details. Keep them separate from APP's platform name.
2. Choose the theme and review its light/dark appearance. Unsaved/default colors can follow the loaded theme; deliberately saved reseller colors remain your settings.
3. Write a short useful hero message and benefits. Add the FAQs, links and contact details your buyers actually need.
4. Review optional sections, ordering and visibility. Remove empty sections rather than padding them with claims you cannot support.
5. Preview desktop and mobile. Check logo alignment, text contrast, buttons, plan names and prices. Make sure nothing is hidden under a header.
6. Save the design and publish the storefront. Also publish the intended plans in Sales > Plans & packages.
7. Open the public page and one individual plan link. Confirm the locked configuration and enabled payment methods.

What to say about the service

Describe what you actually sell and support. Do not claim instant fulfillment, uptime or an enabled integration merely because a design template contains that wording. APP does not supply streams or content sources; only offer services you are authorized to provide.

Some menus provide working content tools; others expose limited setup surfaces. A page being present does not mean a new service is fully automated.

Publish a help article

Open Store > Pages & FAQs (the knowledge-base page). Create an article with a title, URL slug, category and body. Choose Draft while writing; choose Published when ready and save. Open the public article to check it. Edit to correct it; delete only if you mean to remove it permanently.

Storefront FAQs and custom pages

The designer also controls the storefront's FAQ text and supported public-page/navigation content. Use that surface for the buyer-facing design; use the knowledge base for help articles. Check the public links after publishing. Terms, privacy and contact content must fit your business rather than copying unrelated claims.

Custom domains are not yet a completed live-hosting flow

When the domain page is enabled, add the hostname and follow its CNAME/TXT instructions. The reviewed surface records a pending DNS request; managed TLS activation still depends on platform-edge enablement. Keep using the hosted storefront address until APP confirms the domain is actually active. Entering a hostname is not proof of a working HTTPS site.

Media servers

This optional surface can collect draft connection details for supported media-server concepts. The reviewed configuration does not establish a verified automatic fulfillment lifecycle for them. Do not advertise an automated Plex/Jellyfin/Emby sale simply because you saved a draft connection.

These pages help you understand the workspace. They do not replace the underlying payment, service and panel records.

Read reports

Reports summarizes revenue and commerce health, active services, checkout funnel, payment-provider results, top offers and recent panel/payment activity. Use the links to open the relevant operations, payment or plan records when a number looks wrong. Recorded revenue is not a bank settlement report or a full accounting/tax system.

Maintain service status

Open Service status and add a named component, such as a customer-facing service. Choose Operational, Degraded, Partial outage or Major outage and enter a helpful optional message. Later, use the state controls to update it. These are your recorded status announcements, not proof that APP independently monitors every upstream system.

Review abandoned carts

Open Abandoned carts to inspect checkout sessions that did not finish. Use the customer CRM or order links when shown to investigate. A checkout session is not a verified order payment. Do not provision from a cart just because someone entered an email.

1. For a daily check, begin with Today's work and notifications. Open the specific queue behind any action item.
2. Compare report totals with individual records before making a correction.
3. If a status or failure is unexpected, collect the record ID and time and use Contact APP support.

Your buyers ask you for help. You ask APP for help with the platform. Keeping these conversations separate prevents customer issues from disappearing into the wrong inbox.

Reply to your customer

Open Customer tickets. Filter by status if useful, choose the ticket and read the whole conversation. Use the CRM link to see the customer's service and invoices. Write your reply and press Send reply. Close a resolved ticket or reopen it when more work is needed. Buyers use the supported customer-portal ticket route; this is not the owner's reseller inbox.

1. For a platform problem, open Contact APP support and choose New ticket to APP.
2. Enter a specific subject. Pick the Area: General, Billing, Panel connection, Provisioning or Storefront. Use urgent only when service has actually stopped.
3. Describe what you tried, what you expected and what happened. Include workspace, order/service ID, panel connection name, time/time zone and exact error.
4. Press Create ticket. Your request and later replies stay attached to your workspace and route to the master support inbox.
5. Select the same ticket to reply; close it once resolved rather than opening another ticket for the same issue.

Live chat

The current Live chat entry is Coming soon. Use tickets now; the future messaging/chat cards are not a working live-chat channel.

Give each operator their own sign-in. A shared owner password makes it hard to know who changed a service or exposed a secret.

1. Open Staff. If it first shows your workspaces, choose the current workspace's edit/manage page.
2. Use Invite staff, enter the person's email, choose an offered role and send the invitation. Check Pending invitations rather than repeatedly inviting.
3. Review Team members once they join. Where allowed, change a non-owner role or remove the member. Cancel an unneeded pending invitation.
4. Use General for your account name/email. Changing the account profile is different from changing a buyer's customer record.
5. Open Security to change your password and enable 2FA where available. Confirm your password if requested, complete the authenticator verification and store recovery codes privately.
6. Use passkey enrollment/management when shown. Remove a lost or obsolete passkey only after ensuring another sign-in/recovery method works.

Roles are not a promised full permissions matrix

The current role set is Owner, Admin and Member. Workspace-management permissions differ, and operational pages also enforce their own checks. Do not assume a Member has a narrowly limited billing/support role unless tested. Grant the least access needed and ask APP support if a restriction is unclear.

Notifications

The bell and Settings > Notifications show operational alerts, failures and replies. Open an alert to inspect the underlying record. Mark all read clears the unread state; it does not fix the underlying failure.

This page is your fee for using Auto Provision Pro. Customer service invoices and your connected merchant accounts are elsewhere.

1. Open APP subscription and review the current plan, due date and any complimentary test-access notice.
2. For normal paid use, choose the desired monthly plan and the offered payment mode: automatic monthly billing or a one-time payment for the current month.
3. Continue to secure Stripe checkout. Review the amount and frequency before completing it.
4. If an outstanding APP invoice exists, use Pay outstanding invoice instead of creating an unnecessary second purchase.
5. After payment, return and verify platform payment history and restored access if it had been suspended.

What happens if a normal APP fee is overdue

The configured policy gives a 24-hour grace period, then suspends APP access only until payment is verified. It does not delete the workspace, suspend your customers' upstream panel lines or terminate their provider subscriptions. Do not describe APP suspension as remote service suspension.

During complimentary test access

A complimentary grant requires no APP payment for the access it covers; check your account for its expiry. After expiry or revocation, normal purchased access/billing rules apply. The grant itself is not a paid subscription and does not activate future-service modules.

The bubble should be a shortcut to guidance, not something you have to fight on every page. You can close it and return later.

1. Open the Help bubble on the page where you are working. Read the task-specific guidance for that page.
2. Close the open panel when you only want to get it out of the way.
3. Use Hide help for this page when you do not want guidance on that section.
4. Use Hide help on every page to stop help across the app. Use the available help controls to Enable guides when you want them back.
5. If the short on-page guidance is not enough, use this handbook's contents to jump to the complete task.

Your appearance preferences

The top appearance button controls light/dark/system mode. Check form labels, tables, disabled buttons and public previews in the chosen mode. Saved storefront colors remain the reseller's design; switching your admin appearance is not permission to overwrite that brand.

Demo versus your real workspace

The shared demo uses fictional sample data, starts in light mode and resets changes after its configured inactivity period. Your private reseller workspace is where you keep actual panels, customer records and saved settings. Do not enter real provider secrets into a shared demo.

There are two kinds of cards here: features included in the current app, and ideas you can express interest in. They should not be confused.

Payment and panel capacity

Additional gateway choices and panel allowances follow your plan or purchased/granted access. A complimentary grant may unlock extra capacity, but does not supply credentials or credits.

Future module cards

Open a future card to read its purpose and save setup interest if that option is shown. Describe your need without typing secrets. Saving interest is not payment, installation or activation. Do not promise the feature to buyers before it is implemented and tested.

All items on this page are roadmap choices, not activated tools. Read the card, save your interest if useful and continue using the working core feature.

These entries extend the operating model. Use the existing service, invoice and report tools until the proposed extension is actually released.

Read the state before choosing the fix. The right next step depends on whether payment, provisioning or delivery is the part that failed.

Treat this as a practical check, not a promise that the whole product is launch-ready. Keep the test bounded and label the records clearly.

1. Sign in as the invited reseller. Confirm the right workspace and that Setup is easy to find. Check mobile navigation and light/dark contrast.
2. Connect one supported panel and discover named packages/groups. Record what was tested; do not call a login test a provisioning test.
3. Build one clear sample plan with a locked lineup. Publish it and the storefront, then check the public plan on desktop and mobile.
4. Configure your own gateway and email sender. Confirm a real test email arrives. Confirm that customer payment credentials are not the APP owner's billing connection.
5. Run one approved free trial or stated paid checkout, with explicit approval for any money or panel credit use. Verify one remote line, the correct ID/expiry and delivery.
6. Test an agreed renewal on that line using the intended billing/scheduler path, not an unrelated manual Renew button. Verify the same ID extends only once.
7. Check the invoice, receipt, reminder/delivery history and actual inbox. Save any failed step with the precise error and time.
8. Create a platform-support ticket and confirm the reply path. Test only your own authorized records; leave unrelated workspaces untouched.

Finish with a short handoff

Write: what worked, what did not, the record IDs, any money/credits used and the next action. That is more useful than "all good" based only on a green checklist.

If a label changes slightly, follow the task and menu section rather than guessing an old URL. The handbook is written for the reviewed private-testing build, not as a contract for future features.

How this edition was checked

Menu routes, forms, service actions, billing/reminder logic, module catalog and owner controls were reviewed against the current application source on October 1, 2026. This writing task did not charge a card, create a panel line, test all live provider accounts or confirm inbox delivery.