TallyTTally
Jun 14

Use case + roadmap idea: revenue split on Tally payments

I use payment-enabled Tally forms (inline Stripe block, embedded on a client site, tabbed so the visitor picks an option) to sell event registrations. Hidden fields flow in from the page, and after payment Tally redirects to a thank-you page with a token so the buyer lands in the right place. The inline payment UX is exactly why I chose Tally - no bounce to a separate checkout page.The one thing I couldn’t do natively: split each payment between two parties. I have a platform owner and a partner who should automatically receive a percentage of every sale. I confirmed with support that Tally’s Stripe block uses standard Stripe, not Stripe Connect - so there’s no application_fee / destination charge, and every payment lands 100% in one account (and the charge is created under Tally’s own Stripe app).How I worked around it: the receiving Stripe account is set up as a Connect platform, the partner is a connected account, and a daily cron on our backend lists the Tally-created charges and — once each one’s funds settle - transfers the agreed percentage (of net, after Stripe fees) to the connected account, deduped per charge with proportional refund reversal. It works, but it’s a lot of plumbing for “split this payment.”Roadmap nice-to-have: an optional Stripe Connect mode in the payment block - even just an application_fee percentage + a destination connected-account ID (i.e. destination charges / on_behalf_of). That alone would unlock marketplaces, co-hosted events, and partner/affiliate rev-share, with zero external webhooks.
PendingPending
Jun 15, 2026

Thanks for taking the time to share such a detailed breakdown of your use case. This is a great example of a real-world workflow where native revenue splitting would add a lot of value, and we appreciate you explaining both the limitation you ran into and the workaround you built. The additional context around event registrations, partner payouts, and Stripe Connect is especially helpful. We will keep it in mind as we continue improving Tally Payments. Feedback like this helps us better understand how people are using Tally in production and where we can reduce the amount of custom infrastructure required. Thanks again for the thoughtful suggestion.