By Fiona Blake, Payments Documentation Analyst, 12 years writing recipient support and payout operations guides
A trolley payments search can fail because the words sound familiar while the roles are not. Recipient, sender, payout method, batch, status, fee schedule, tax form, and API key do not belong to the same person. A recipient waiting for money does not need the same page as a finance manager or developer. This glossary is informational only. It is not Trolley, not a login page, not a bank, not a payout processor acting for you, not a tax service, and not a support desk.
Term: Trolley payments
In plain language, trolley payments usually means payout activity involving Trolley’s platform, such as recipient onboarding, payout method setup, payment status, tax workflows, or business payout automation.
Trolley describes itself as payout infrastructure, not a payment processor. Its about page says Trolley helps internet businesses onboard, verify, and pay people globally while keeping compliance and operational control.
That distinction matters because the word “payments” can mislead recipients. Trolley is not usually the company that hired you, approved your invoice, tracked your commission, hosted your marketplace sale, or calculated your creator balance.
A safe first question is not “Where is Trolley holding my money?” It is “Which company is paying me, and did that company use Trolley as part of the payout flow?”
Term: Recipient
The recipient is the person or business being paid.
A recipient might be a creator, freelancer, seller, affiliate, contractor, host, guide, artist, supplier, vendor, clinical-trial participant, royalty recipient, or marketplace user. The exact label depends on the company sending the money.
Trolley’s site describes tools for managing recipient interactions from onboarding and communication to tax compliance.
A recipient should focus on verified setup, payout status, method choice, and sender instructions. A recipient should not use a public article to submit banking, tax, or identity details.
Common friction: the recipient recognizes the platform that owes the money but not the payout tool name. That can happen when a company uses Trolley behind the payout flow.
Term: Sender
The sender is the company, platform, marketplace, network, or organization that owes the payout.
The sender often controls the amount, eligibility, approval timing, payout calendar, recipient record, and support route. Trolley may provide infrastructure, but the sender usually knows why a payment exists.
Ask the sender when:
The amount does not match your platform balance.
The payout reason is unclear.
The sender name looks unfamiliar.
The expected payout date has passed.
The recipient email appears to be wrong.
The payout was never approved inside the platform.
A useful support message is specific without being private: “The payout amount does not match my dashboard balance,” or “The invite was sent to this email address, but my account uses another one.”
Do not send full bank numbers, full card numbers, passwords, codes, tax IDs, identity files, or private screenshots to an unofficial guide page.
Term: Recipient invite
A recipient invite is a setup message that may appear after the sender creates a recipient profile.
Trolley support says that once a new recipient is created in the Trolley Dashboard, the recipient receives an email prompting them to log in and complete account setup.
The invite should match a real payout relationship. The sender should be familiar. The email address should match the address used with that sender. The payout should connect to recent work, sales, royalties, commissions, invoices, or platform earnings.
Common friction: the invite goes to an old inbox, then the recipient tries to continue setup from a newer email. Another common issue: the invite opens in one browser profile, then the recipient returns later in a different profile.
A guide can explain these patterns. It should not ask the reader to paste invite links or account credentials.
Term: Payout method
A payout method is the route used to send money to the recipient.
Trolley’s product materials describe payouts through options such as digital wallets, bank transfers, PayPal, and other methods across global recipient programs.
That does not mean every method is available to every recipient. The sender’s setup, country, currency, recipient type, tax status, verification status, and payout program rules can affect what appears.
A missing method does not always mean the account is broken. It may mean the sender did not enable that method for that recipient profile or location.
Payout method changes should happen only through verified account flows, the paying company’s instructions, the official website, the support page, or the help center. Do not search for a random “Trolley bank update” form and enter money-moving details.
Term: Payment status
A payment status is a label that shows the current state of a payment.
Trolley support says all payments have a status to indicate what state they are in. Trolley’s developer blog also discusses payments moving through batches, statuses, and webhooks.
A status is not the same as a full explanation. A pending payout can involve sender approval, batch timing, incomplete recipient setup, payout method review, tax steps, identity checks, banking rails, country or currency handling, or the sender’s payout calendar.
Safe details to mention in support:
Visible status.
Sender name.
Expected payout date.
General method type.
Amount mismatch, if visible in the verified flow.
Unsafe details for unofficial pages:
Full card number.
CVV.
Full bank account number.
Routing number.
Tax ID.
Government ID.
Identity document.
One-time code.
Private payout screenshot.
A public article cannot inspect a payout record or approve a payment.
Term: Batch
A batch is a group or processing unit for payments in a payout workflow.
For a recipient, the batch may be invisible or only indirectly reflected in a status. For a finance or developer team, the batch can matter for approval, reconciliation, processing, reporting, status tracking, and error handling.
Trolley’s developer material describes the payment journey through batches, statuses, and webhooks.
Common friction: a recipient asks “Why is my payout pending?” while the sender’s finance team is waiting on a batch step. The recipient cannot fix that from a public guide. The sender or official support route has to explain what the next account-specific step is.
Businesses should write recipient support copy that explains what recipients can do and what belongs to the sender.
Term: Fee schedule
A fee schedule describes which fees apply under the account’s setup.
Trolley support says dashboard users can view and manage the fee schedule under Settings and Fee Schedule. That makes exact fee claims account-specific.
A public trolley payments guide should not promise one fee for every sender, recipient, country, currency, or method.
Fee confusion usually appears in small ways:
The recipient sees a lower net payout than expected.
Finance assumes every country costs the same.
Support cannot explain who covers a method fee.
Product publishes payout instructions before fee ownership is decided.
Recipients should check the verified payout screen or ask the paying company. Businesses should confirm pricing, method costs, currency treatment, and fee ownership through official materials or account contacts before publishing recipient-facing copy.
Term: Tax workflow
A tax workflow is the process used to collect, validate, withhold, report, or file tax-related payout information.
Trolley’s platform materials describe workflows that include withholding taxes where needed and generating or e-filing end-of-year tax forms.
A general article can explain that tax steps may appear in payout setup. It should not tell a recipient which tax form applies to them. It should not collect tax IDs, identity documents, bank details, or screenshots. It should not promise that a tax step will clear or that a payout will release by a specific date.
For tax-specific decisions, use verified sender instructions, official resources, the policy page, or qualified professional advice.
Tax content is where a guide can become risky fast. Explanation is fine. Personal tax determination is not.
Term: API key and API secret
API keys and secrets are developer credentials, not recipient support information.
Trolley’s developer documentation says the API manages global recipients, payouts, tax forms, and verifications through REST APIs and SDKs. It also says access uses an API Key and API Secret pair.
Developers should handle those credentials like live access to sensitive payout operations. They should verify sandbox versus live behavior, storage rules, staff permissions, webhook mapping, status handling, recipient creation, audit logs, and error handling.
Never paste live API keys, API secrets, recipient bank details, tax identifiers, identity files, payout records, or screenshots into public tickets, chat rooms, article forms, or shared documents that do not require them.
A recipient does not need API documentation to ask about a missing payout. A developer should not use a recipient FAQ to design payment status logic.
Term: Verified route
A verified route is the official path for account-specific action.
For trolley payments, that might be the paying company’s dashboard, a verified payout setup flow, the official website, the support page, the help center, or the relevant policy page.
A safe guide should point readers to verified routes. It should not claim to recover accounts, verify payout status, change payout methods, collect tax forms, approve identity checks, process money, or reset API access.
The privacy boundary is firm:
No passwords.
No one-time codes.
No full card numbers.
No CVV.
No bank account numbers.
No routing numbers.
No tax IDs.
No government IDs.
No identity documents.
No API secrets.
No private payout screenshots.
A glossary can make the topic easier to understand. It should not become the place where money-moving information is submitted.
FAQ
What are trolley payments?
The phrase usually refers to Trolley-related payout activity, such as recipient onboarding, payout method setup, payment status, tax workflows, or payout automation for businesses sending money to recipients.
Is Trolley the company that owes me money?
Not always. Trolley may provide payout infrastructure. The company that hired you, hosted your sales, tracked your commissions, or manages your creator, seller, contractor, or vendor account often controls the payout relationship.
Why did I receive a Trolley invite?
A company may have created you as a recipient so you can complete payout setup. Trolley support says new recipients receive an email prompting them to complete account setup.
Are Trolley payments instant?
Do not assume that. Timing can depend on sender approval, payout method, country, currency, recipient setup, tax or identity steps, banking rails, batch processing, and account-specific rules.
Why is my payout method missing?
The sender may not have enabled that method for your recipient profile, country, currency, payout program, or account status. Use the verified payout flow or ask the company paying you.
Can this article check my payout status?
No. This article is informational only. It cannot access payout records, process money, change payout methods, approve identity checks, submit tax forms, or contact support for you.
Is Trolley relevant for developers?
Yes. Trolley provides developer documentation for APIs and SDKs related to recipients, payouts, tax forms, and verifications. Developers should use official documentation and protect API credentials.
What should I never enter on a trolley payments guide page?
Never enter passwords, one-time codes, full card numbers, CVV, bank account numbers, routing numbers, tax IDs, government IDs, identity documents, API secrets, or private payout screenshots into an unofficial informational page.