Marketplace payouts

Thousands of payments. A queue of five.

At volume the interesting number is not how many payments settled, it is how many needed a person. Payvol is built so the clean ones match themselves and only the strange ones reach an operator.

Start building Other situations

Request · available Observe · in development Reconcile · in development Connect · planned

The queue is the product

Volume does not create the work. Ambiguity does.

Ten thousand payouts that land exactly as expected cost nothing to run. Fifty that arrive short, twice, late or unlabelled cost a support team its week, because each one starts as an unanswerable question in an inbox.

Everything explainable is already explained

Each settlement is weighed on five axes before anybody sees it. What reaches the queue arrives with the reason attached, so the first minute of the investigation has already happened.

One lookup instead of an investigation

The identifier ties a support ticket to a settlement directly. The answer is a state and a date rather than a query across two systems and a guess.

Every payout is its own artifact

Batch creation produces thousands of independent requests, each with its own identifier. A problem with one is a problem with one, not with a batch that has to be reprocessed.

Honest about the ceiling

Nothing here has run at volume. The design has no shared bottleneck we know of, and that is a different sentence from having measured it under load.

How it works

Issue, absorb, escalate.

Issue

Create a request per payout, in bulk
Deliver them however your platform already does
Record each identifier against your own payout id

Absorb

Settlements match themselves as they arrive
Clean payouts never appear in any queue
Aggregation handles split payments in order

Escalate

Only unresolved cases surface
Each carries its verdicts and flags
Answering a customer is a lookup, not a search

Honest about the fit

What we have not proven here.

This is the situation where our lack of production experience matters most, so it is worth being blunt.

No load testing The reconciliation library is deterministic and fixture driven. It has never been pointed at a hundred thousand records.

No batch tooling yet Creating requests in bulk is a loop over the same call. Ergonomics for that, and for retries, are not written.

Payout scheduling is yours When a payout is due, and whether it is held, belongs to your platform. This starts when you decide to pay.

Support tooling is a library, not a screen The lookup exists as a function. Turning it into something a support agent can use is work you would do, or we would do together.

Connect, which would carry the classification into the system that posts it, is planned. Today the handover is a record your own integration reads.

Try it on last month's exceptions.

Run the library over payouts you have already settled and see how many would have explained themselves.

Open the app B2B invoicing