Frequently asked questions

Per order line, per rule, per recipient.

The app starts from the line’s gross amount (unit price times quantity). If the rule’s basis is Net sales, it subtracts whichever deductions you switched on: discounts allocated to that line, a share of the order’s shipping charge, and the product’s unit cost from Shopify. If the basis is Gross sales, nothing is subtracted. The result, floored at zero, is the basis.

The basis is multiplied by the rule’s rate to give the line’s earned amount, and that amount is split between the rule’s recipients by their percentages. Every intermediate figure is rounded to two decimal places, half up. The documentation has a worked example with the numbers.

Three things, each an independent switch on the agreement’s Deductions panel, and all of them only apply on a Net basis.

• Deduct discounts. The discount Shopify allocated to that line.
• Deduct prorated shipping. The line’s share of the order’s shipping charge, split across the order’s shippable lines by weight. Digital items are skipped entirely, and if no weights are set anywhere on the order it falls back to splitting by price.
• Deduct unit cost. Shopify’s “Cost per item” for that variant, times the quantity. A product with no cost set in Shopify deducts nothing rather than being guessed at.

If Handle refunds is on for the agreement (it is by default), a refund writes a negative entry against the same rule, for the refunded fraction of the line, for each recipient. The ledger is append only, so the original entry stays and the reversal sits beside it.

Repeated partial refunds are capped: the running total reversed on a line can never exceed what that line originally earned. If the rule has an advance attached, the refund also releases the recoup progress that the original sale created.

A refund recorded before the period is paid simply reduces that period’s batch. A refund recorded after the money has already been sent cannot be clawed back; the negative entry nets against whatever that creator earns next.

Yes, and that is the only way the app will let you do it. On a live rule the rate field is read only and you use Update rate instead: you give a Change effective date and a New rate (%), the existing rule is frozen with an end date, and a copy of it starts at that date on the new rate.

Both versions then live in the same agreement with windows that do not overlap, so earnings before the change keep the old rate and everything after it uses the new one.

Yes, deliberately. Every active rule covering a product earns on it independently, with its own rate, its own recipients and its own ledger rows. That is how a per-author stack, or a print rule and a digital rule at different rates, is expressed.

The app blocks overlapping rules inside one agreement only when they would genuinely double pay. If their effective windows do not overlap, or their order criteria are provably mutually exclusive (one EU only, one non-EU, say), they are allowed to share products.

On the first day of the next payout period, for the period that just closed. A monthly rule batches on the first of the month, a quarterly rule on 1 January, 1 April, 1 July and 1 October, and an annual rule on 1 January. A background sweep runs hourly, so a period is picked up within an hour of opening.

Generate payouts now runs the same check on demand, under the same calendar rule. Pay out current period early is the exception: it batches what has been earned so far in the period that is still open. Anything that accrues afterwards forms a later batch of that same period, so nothing is stranded, but money sent early is money a later refund cannot reverse.

Only after you approve a batch and then press Send Approved Payouts. Approving on its own moves nothing. There is no setting that sends payouts automatically.

A payout line is marked paid only when PayPal reports that the item succeeded, never because the request was accepted. Anything PayPal still has in flight stays in processing and is polled hourly until it resolves one way or the other.

Your own PayPal credentials, entered in Settings: the Client ID and secret of a REST app from your PayPal developer dashboard, and a mode of Sandbox or Live. Test connection checks them before you rely on them.

PayPal has to enable the Payouts feature on your live account before live payouts will work. Sandbox works right away, which is the sensible place to prove the whole loop first.

Payouts run from your account to your creators. We are not a payment processor, we never hold the money, and there is no path in the app that sends a payout from anyone’s credentials but yours.

The app records the amounts Shopify reports on the order, shows them with a dollar sign throughout the admin, and submits PayPal payouts with the currency set to US dollars. There is no conversion step anywhere in the app. If your store sells in another currency, talk to us before you send a live batch.

No. Set a creator’s Payout method to manual and their lines are left out of the PayPal send entirely, never auto-failed. You settle them however you like and mark the line paid on the batch, recording the date, the method and a reference.

There is also Record payment on the Payouts page for money paid outside a batch, including payments you made before installing the app. Those are applied to that creator’s oldest unpaid periods first.

Nothing, unless you turn the creator portal on. It is off by default and is a Pro plan feature.

With it on, a creator signs in with their email address and sees their own earnings: period totals, their statement of account, their payout history, reports, and the agreements they are on. They never see another creator’s figures, your other deals, or anything in your Shopify admin.

Two settings narrow it further. You can stop creators downloading line by line earnings detail, leaving them with period totals and their payout history. You can also stop creators sharing read only access with a manager or accountant. Where that sharing is allowed, the guest sees the dashboard, reports and payout history only, can change nothing, and cannot pass access on.

Two things, and only if they have an email address on file.

• A payout report, sent once a payment to them is confirmed paid.
• A statement, on a schedule. The sweep runs monthly against the previous calendar month, and a creator can set their own cadence to monthly, quarterly or annually from the portal, or switch statements off.

Emails go out under your store’s name with your address for replies. Scheduled statements and reports need the Growth plan or higher.

Yes, with two tools inside the agreement editor.

Historical order pull replays every order in the agreement’s own effective window back through the calculator, so the deal’s full sales history lands in the ledger as earned and owed. Advances are read but not moved by it.

Data cleanup handles the harder case: historical order lines whose Shopify variant no longer exists, so nothing could match them. It scans for lines that resemble the agreement’s products, ranks the candidates, and lets you confirm or dismiss them one at a time before anything is credited.

Yes, at three levels.

• Store wide, in Settings: a list of excluded order tags, and a switch that makes B2B company orders accrue nothing for any rule. The usual reason is crowdfunding fulfilment, where creators were already paid under campaign terms, and wholesale settled under separate terms.
• Per agreement: the same two carve outs, scoped to one deal, so an order can stop paying that deal while still paying everybody else’s.
• Per rule, under Order criteria: restrict a rule to or away from B2B orders and to a list of countries.

Excluded lines are counted on the creator’s statement as entries that were not eligible, so the period does not just silently come up short.

The free tier covers a small catalogue and two creators with manual settlement. Sending payouts through PayPal and the creator portal are Pro features; scheduled email reports and statements and connecting a second store start at Growth. See the App Store listing for current pricing and limits.

Your access tokens are deleted immediately, so the app stops reading anything from your store the moment it is removed.

Everything else is kept until Shopify sends the store erasure request that follows an uninstall, about 48 hours later. At that point all of it goes: creators, agreements, rules, the ledger, payout batches and history, products, and the store record itself. Reinstalling inside that window brings your setup back intact.

There is nothing to export on the way out that you cannot export while the app is installed, so take your ledger CSV before you uninstall if you want to keep it.