Stripe Connect Direct Charges Marketplace Architecture is the foundation of Amuthi’s payment system. When a client pays a photographer £200 through Amuthi, the money moves directly from the client’s card to the photographer’s Stripe Connected Account. Amuthi does not touch the funds or hold them, even briefly. Instead, it collects a platform fee as a Stripe application fee, deducted before the remaining funds settle into the photographer’s bank account. This architectural decision is one of the most consequential technical choices in the Amuthi build, driven not by engineering preference but by compliance, scalability, and operational simplicity.
Why Direct Charges: The FCA Problem
If Amuthi held client funds- even briefly, even in a Stripe balance- it would qualify as an Electronic Money Institution under UK FCA regulation. Obtaining an EMI licence takes six to twelve months and costs £50,000 to £100,000 in legal, compliance, and audit fees before the first payment is processed. For a startup building a payments layer, this is typically either a showstopper or a multi-year delay.
Stripe Connect’s direct charge model avoids this entirely. In a direct charge, the PaymentIntent is created on the connected account (the photographer’s Stripe account), not on Amuthi’s Stripe account. The money is Stripe’s liability from the moment it leaves the client’s card. Amuthi is a facilitator, not a payment processor. No EMI licence required. Engineering complexity reduced by approximately 60 percent.

Stripe Connect Direct Charges Marketplace Architecture: The 5-Step Payment Flow
Step 1: The photographer completes Stripe Connected Account onboarding: name, bank details, identity verification. This is Stripe’s KYC process, not Amuthi’s. Stripe handles the compliance.
Step 2: The client initiates a booking with payment. Amuthi’s backend creates a PaymentIntent on the photographer’s Connected Account using Stripe Connect Direct Charges, specifying an application fee amount (Amuthi’s platform margin, typically 5 to 10 percent of the transaction).
Step 3: The client pays through Stripe Elements embedded in Amuthi’s checkout. PCI compliance is Stripe’s responsibility, Amuthi never sees raw card data.
Step 4: Stripe processes the payment. The charge appears on the connected account. The application fee is deducted before settlement.
Step 5: Stripe settles to the photographer’s bank account on its standard payout schedule (typically 2 business days). Amuthi’s platform fee settles to Amuthi’s Stripe account on the same schedule.
The Dashboard Complexity in Stripe Connect Direct Charges Marketplace Architecture: Joining Two Data Source
The photographer’s earnings dashboard in Amuthi requires combining two data sources: Amuthi’s booking records (which know what the booking was for, which client, which session type) and Stripe’s reporting API (which knows what the actual payment amounts and statuses were). These are different systems with different data models, and the join query is not trivial.
Amuthi caches this combined view hourly. The cache is invalidated when a new payment event arrives from Stripe’s webhook. On a cache hit, the dashboard loads in under 200ms. On a cache miss, the Stripe API call adds approximately 800ms. For a professional checking their earnings at the end of the day, this is invisible. For a professional checking earnings immediately after a payment, the freshness delay is acceptable, the confirmation SMS has already arrived.
Refunds and Disputes in Stripe Connect Direct Charges Marketplace Architecture
Refunds initiated through Amuthi’s dashboard call Stripe’s refund API on the connected account. The funds return to the client from the photographer’s Stripe balance, Amuthi does not participate in the money movement. The platform fee is also refunded in full on a full refund. Chargebacks are handled between the client and Stripe, with the connected account (the photographer) bearing the dispute cost. This is by design the professional is the merchant of record.
FAQ
Does this architecture scale?
Yes. Stripe Connect supports millions of connected accounts. The architecture does not change with volume.
Can SynthWeb build a similar payments layer for other marketplace products?
Yes. Direct-charge Stripe Connect is our standard architecture for marketplace MVPs. See /engineering-pods for how we scope these engagements.
What if a professional needs to accept cash or in-person payments too?
Amuthi tracks in-person payments as a separate touchpoint type. A manual entry that updates the client’s balance without going through Stripe. The CRM view shows the full picture regardless of payment method.
Also Read:
Technical Debt in Year 2: How We Build MVPs That Don’t Need a Rewrite at Series A






