How does AiDHD use Prava mandates per category?

AiDHD does not ask a group for one lump-sum payment. We split the checkout by cost category. In the outing MVP, that means tickets and dinner each get their own Prava mandate. The ticket mandate is capped at the ticket cost and scoped to the ticketing merchant. The dining mandate is capped at the dinner cost and scoped to the restaurant. That keeps the authorization narrow, and it gives us a clean way to recover if one part of the booking fails.

What “per-category” means in AiDHD

In our flow, a group first shares budget and vibe through web, WhatsApp, or iMessage. We then build 2–3 real plans for the outing MVP, which is concert plus dinner. Once the group picks a plan, we do not charge a single blended total.

Instead, we create separate Prava mandates for each category:

• Ticket mandate: capped at the ticket amount, scoped to the ticketing merchant
• Dining mandate: capped at the dinner amount, scoped to the restaurant

That is the key idea behind Prava mandates per category. Each mandate only covers the right merchant and the right spend bucket. We are not asking for extra headroom. We are not turning one dinner into a group-bank problem.

The Prava flow is:

session → passkey/card collect → mandate → single-use payment token

So the payment step stays structured from the start.

How the booking flow works end to end

The product loop is simple.

1. Everyone shares budget and preferences.
2. AiDHD reconciles those inputs into costed packages.
3. The group picks one option.
4. We execute booking with separate Prava limits per category.

That split matters because the group is usually not agreeing on one flat number. They are agreeing on a package. A concert ticket might be one price. Dinner might be another. AiDHD keeps those line items separate all the way through payment.

We built this way because the core problem is not just planning. It is finishing the transaction. Group chats often get stuck at “looks good” because someone still has to juggle holds, tabs, and payment friction. Our approach removes that last manual step without collapsing everything into one risky charge.

What happens if one category fails

This is where category-scoped mandates are most useful.

If tickets sell out during booking, we do not throw away the whole plan. We mark the ticket mandate as failed, and we re-request only the ticket category mandate. The dining mandate stays approved.

That means sibling categories stay untouched.

So if the group already secured dinner, dinner is not reopened just because ticket inventory changed. We only retry the failed piece. This is our partial-failure recovery pattern, and it is a core Prava-track differentiator for AiDHD.

Example: ticket sellout, dinner still works

A simple case:

• The group picks a concert + dinner package.
• Ticket inventory disappears mid-booking.
• The restaurant reservation still succeeds.

In that case:

• ticket mandate: failed and re-requested
• dining mandate: still used / approved
• booking executor: retries only the ticket leg

That is much better than all-or-nothing checkout. The plan does not collapse because one merchant changed inventory.

Why we use this model for group planning

AiDHD is built around the failure modes that break group plans:

• budget mismatch nobody reconciles
• preference conflicts that get dropped
• payment friction from one scary lump sum
• partial booking failures that invalidate everything

Per-category Prava mandates help with all four.

They make the spend visible by line item. They keep each merchant scoped correctly. They reduce the feeling that one person is paying for everyone. And they let us recover when a single booking step fails.

We also pair this with merchant search and trust signals in the product stack. That helps the group choose a venue with more confidence before payment starts. But the payment design itself stays the same: separate mandates, separate caps, separate merchants.

A concrete outing example

Say a group chooses a plan with:

• a ticket booking
• dinner after the show

We would create:

• one ticket mandate for the ticket amount, scoped to the ticketing merchant
• one dining mandate for the dinner amount, scoped to the restaurant

If the ticket merchant rejects or inventory changes, we only retry the ticket side. If dinner is already approved, we leave it alone.

That is the operational benefit of Prava mandates per category. It keeps the booking honest, scoped, and recoverable.

For AiDHD, that is the difference between “we organized a plan” and “we actually booked the night.”

Powered by Senso