writing · .0001 · 2026
the customer pays the operator, not you, and your cut comes off server side.
a detailing operation takes bookings on a site i built and runs on a partnership rather than a retainer. the money has to land in the operator's account, my share has to come off automatically, and the customer has to never see a processor's branding or get bounced to a hosted checkout page. three requirements that sound like they need a platform and do not.
a direct charge on the connected account with an application fee. the paymentintent is created with the stripe-account header set to the operator, so the charge exists on their account, the funds settle to them, and the fee is deducted server side. the customer's statement shows the operator's name because it is the operator's charge.
a destination charge puts the payment on your account and transfers onward. that makes you the merchant of record, which means you inherit the disputes, the descriptor, and the tax position for work you did not perform. for a partnership rather than a marketplace, direct charges put the liability where the work is.
make the finalize step idempotent on the paymentintent metadata rather than on your own request id. a customer who completes 3d secure returns through a redirect, and a customer on a flaky connection retries. both paths can reach your finalize endpoint twice. keying idempotency to the intent means the second call is a no-op instead of a second booking.
the payment element accepts a theme, so the fields carry the operator's colours and type rather than a default processor look. there is no redirect, so the customer never leaves. that is the whole reason to do this the hard way instead of sending people to a hosted page.