The short answer
Psychic Chat is a live reading marketplace built by AR Digital Solutions. Customers hold a wallet balance, readers set availability, sessions are billed by the minute, and earnings flow through to payouts. It's the same model as any per minute advice platform, and the difficulty lives in the money, not the chat.
The pieces, and what each one has to survive
- A wallet where every top up, deduction and refund traces to a payment record rather than a balance field.
- A session meter both sides trust, running server side, with a defined start and stop.
- Reader availability that reflects reality, including the reader already mid session.
- A queue customers can see, with a position and an honest wait estimate.
- An earnings ledger per reader that reconciles to the cent against what the provider settled.
- Payouts on a schedule, with a holding period that covers chargebacks, and a dispute path with the evidence attached.
The five hard problems in any per minute marketplace
If you run a paid advice line, this is about you whether you sell readings, telehealth consults, tutoring hours or paid technical support. The subject matter changes. The engineering doesn't.
Billing accurate to the second.
The meter runs server side, because a clock in a browser can be paused, throttled by a sleeping phone, or edited by anyone who opens dev tools. Then you define the moment billing starts, and it isn't when the customer taps connect. It's when both parties are actually joined, or customers pay for a provider who never answered. You need a rounding rule published before purchase, and a plan for the wallet that empties mid sentence: a warning, a top up offer in session, and a hard stop that doesn't feel like theft.
Connections that drop.
A dropped mobile connection isn't a finished session. You need a heartbeat, a window for the customer to rejoin the same session against the same meter, and a rule for who wears the gap. Most operators eat the lost minutes as goodwill. That decision is easy. Building the session log that applies it consistently, rather than arguing case by case, is the part people skip.
Holding funds and releasing payouts.
Money arrives up front, the service is delivered over the following minutes, and the provider is owed later. Those timings never line up. A card payment can be clawed back months afterwards, so paying providers instantly means funding every chargeback yourself. That's why a holding period exists, and why each provider's earnings ledger has to reconcile against the payment provider's settlement statement rather than your own arithmetic. Onboarding, identity checks and tax details belong in the same conversation, and those are questions for your accountant. Our Stripe integration work is usually where this lands.
Disputes and refunds.
Someone will say the provider was unhelpful, the connection was poor, or their teenager spent the money. You need the duration, the timestamps, the transcript where you're permitted to hold it, and what was already paid out, on one screen. You need a threshold under which refunds are automatic, because a human reviewing a four dollar dispute costs more than four dollars. And you decide in writing, before launch, whether a refund comes out of platform margin or provider earnings.
Availability and queueing.
Online isn't a status, it's a claim. A provider can be logged in and already busy, logged in and ignoring requests, or offline having forgotten to say so. Real availability is a state machine, not a toggle, plus a rule for the provider who closes their laptop with three people waiting. Those customers need a position and an estimate that degrades slowly rather than lying immediately. The queue is an economic lever too, because whoever the platform routes work to is who earns.
How a build runs
1. We map the money.
Pricing, rounding, commission, holds and payouts, before anyone draws a screen.
2. We agree scope and price, with a written list of what version one leaves out.
3. We build it on a staging link you can watch, failure cases included.
4. We launch and stay close.
The first weeks of live money are when the edge cases arrive.
Who it's for, and who it isn't
It suits operators running paid live sessions between customers and independent providers, in readings, coaching, tutoring or advice lines where the clock is the product.
It isn't for a single practitioner selling their own time. That's a booking page and a payment link. Selling goods across many vendors instead of time? That's multi vendor marketplace development.
Why bring this here
We've built the money side before.
Wallets, commissions, holds and payouts are where marketplaces sink, and this isn't our first.
In house developers, who also run the servers under it.
No lock in contracts, and you own the source code.
"We were quoted a lot less elsewhere."
Usually for the chat. The chat is a fortnight. The wallet, the meter, the ledger and the payouts are the job, and a quote that skips them finds them later at your cost.