Hyperwallet and Trolley Payout Handoff Planning: Evidence and Fields to Prepare

Plan a Hyperwallet or Trolley payment handoff by separating locked obligations, export mapping, provider checks, and reconciliation evidence. This is not a provider-ready upload template.

Allocora Team Oct 05, 2026 5 min read
Editorial workflow showing a locked calculation run producing a generic payout export for two external rails, with payment confirmations returning for reconciliation.

Hyperwallet and Trolley are payout rails: they provide services for moving money to recipients. A payout calculation system has a different job: determine the obligation, explain the calculation, and preserve review evidence.

For the broader calculation-versus-execution boundary, see Allocora vs payout rails.

Quick answer

Before preparing a Hyperwallet or Trolley payment batch, calculate and lock expected obligations, review exclusions, and prepare the recipient references, payable amounts, currencies, and traceability fields required by your downstream process. Map the reviewed export to the provider's current account-specific format, validate it there, and reconcile confirmations after payment. Collect bank, tax, and payout-method details through the provider's supported process, not in the calculation export.

Separate calculation from money movement

The calculation layer should answer:

  • Who has an expected obligation?
  • What amount has been calculated and approved?
  • Which rule created the amount?
  • Which source rows support the amount?
  • Which amounts are excluded from the payment handoff, and why?

The payout rail should answer:

  • Is the recipient onboarded?
  • Is the payout method valid?
  • Can the payment be executed?
  • What payment outcome is recorded?
  • What external payment ID was created?

Use this separation to keep calculation evidence distinct from payment execution and to make excluded-row review explicit. Assign an owner to both sides of the handoff.

Handoff and evidence fields to prepare

FieldPurpose
payee_referenceCrosswalk to the recipient in Hyperwallet, Trolley, or AP
payee_nameHuman review field
amountReviewed amount included in the payment handoff
currencyCurrency of that amount
memoNote permitted by the destination's schema
statement_referenceLink to statement evidence, when required
calculation_run_idLink to locked calculation evidence
hold_reasonExclusion evidence kept with the close package, not an instruction to pay
source_periodClose-period context

These are planning fields, not a Hyperwallet OneBatch schema, a Trolley CSV template, or a native Allocora integration. Do not assume the selected Allocora export includes every field above. Configure the needed references, retain any provider-ID crosswalk, and verify the generated file against the destination requirements before upload.

Hyperwallet planning notes

Hyperwallet describes its service as payout infrastructure for sending and disbursing funds. For your program, confirm the supported submission method, recipient identifiers, required fields, and response format in the current Hyperwallet integration documentation.

Before handing off a file, confirm how each reviewed obligation maps to a recipient, how the provider reference will be retained, and how rejected or returned payments will be reviewed. Keep bank credentials out of the calculation export and collect payout-method details through the provider's supported onboarding flow.

Trolley planning notes

Trolley's batch documentation describes API-created batches and dashboard CSV uploads. Payments belong to a batch; the destination format and recipient requirements must still be validated for your account. An Allocora calculation export is a mapping input, not a guarantee of a valid Trolley upload.

Useful planning questions:

  • Which payee identifier maps to the Trolley recipient?
  • Which memo should appear in the payout record?
  • How are excluded obligations kept out of the payment batch?
  • How are failed or returned payments retained for review?
  • Which provider references connect the batch and its payments to the locked close evidence?

Hold and threshold handling

Review calculation-side decisions separately from provider-side checks. In Allocora's documented payout CSV workflow, explicitly held, below-threshold, and zero-value rows are excluded from the payment file; a negative payment-ready amount is a blocker, not a payment instruction. Check the frozen settlement decisions and generated export before handoff.

Separately validate the provider's recipient status, payout method, applicable tax or compliance requirements, supported currencies and routes, and payment minimums. Do not treat an Allocora export as evidence that those provider checks have passed. For example, Trolley documents recipient-readiness and payment-minimum requirements in its payment workflow.

Keep held or excluded obligations in the close evidence. Do not rely on a hold_reason column to stop payment unless the downstream workflow explicitly implements and tests that behavior.

Reconciliation after payout

After Hyperwallet, Trolley, AP, or another rail executes payment, retain the original confirmation file and map the fields supported by the reconciliation workflow:

  • Payee reference or email for matching.
  • Paid amount.
  • Currency, paid date, payment reference, and note where available.

Allocora's documented confirmation mapping uses those fields. Preserve provider status, failure, return, and reversal attributes as raw confirmation evidence, or include relevant status text in the supported note field. They are not separate structured provider-status fields in that mapping.

Compare matched actual amounts with the locked expected obligations, and review unmatched records, residuals, and variances. An amount match does not establish that a provider payment is final: review the provider's own outcome evidence before closing the reconciliation. Document how subsequent returns or reversals will be handled without overwriting the original evidence.

Controls to check before handoff

  • Keep commission or royalty business logic in the reviewed calculation, not in a transformed payment file.
  • Retain source-row evidence and the locked run reference.
  • Reconcile transformed file totals to the included obligations.
  • Inspect exclusions and provider validation results before submitting a batch.
  • Limit sensitive payout-method data to the systems and people that need it.

These controls require clear ownership and verification; separating systems does not guarantee that a payment will be correct or accepted. For the evidence-retention side, read Audit-Ready Settlements.

FAQ

Does Allocora execute Hyperwallet or Trolley payments?

No. Allocora's role is calculation, export preparation, and reconciliation evidence. Hyperwallet, Trolley, AP, a bank, or another external payout process executes payment. This guide does not provide a native connector or a provider-validated upload template.

What should the export source of truth be?

Use the locked calculation and settlement evidence for the expected obligations and included payment amounts. Use provider confirmations and subsequent outcome updates for what happened after submission. Retain the relationship between the two.

Related Articles