Building Payment Integrations for a Creator Live-Streaming App
DBB Software built full-scope payment integrations for a creator live-streaming app, from Apple and Google in-app subscriptions to Stripe payouts for creators' earnings.
Industry
Media & Entertainment
Service
Mobile App Development
Team
2 Team Leads (FE and BE), BE Developers, Mobile Developers, DevOps Engineers, QA Engineers
Project State
May 2023 - May 2024
Country
NDA
About the Client
The client is a startup that built a social live-streaming app for creators, released on iPhone and Android in 2024. Creators broadcast live to their followers from a phone or from studio software. Viewers browse a full-screen feed of live streams, interact with creators during broadcasts and support them through paid subscriptions.
The Client's Initial Request
The client engaged DBB Software to build its payment layer because creators earned from paid subscriptions and needed a reliable way to be paid.
Creator Subscriptions Through the App Stores
Viewers paying creators monthly through Apple's and Google's in-app billing, which Apple's App Store rules require for digital subscriptions.
01
Customizable Subscription Pricing
Each creator setting their own monthly price, with no manual work in the store consoles.
02
Payouts to Creators
Creators paid to their bank accounts, with identity checks handled by the payment provider.
03
Trustworthy Payment Records
Every purchase verified, every renewal and refund reflected, and test purchases never counted as real money.
04
Accurate Creator Balances
Earnings staying correct when spending and withdrawals happen at the same moment.
05
The Deliverables
DBB Software built the payment layer end to end, from store billing to creator payouts.
Per-Creator Store Products
Each creator's chosen price became a real subscription product in the app stores, created by the backend.
When a creator picked a price tier, the backend created the product through the App Store Connect API and, in production, submitted it to Apple's review.
If Apple reported missing details, the submission retried 5 times, 5 seconds apart, and the review status was checked every 15 minutes. Dev and stage environments skipped the review.
With Google Play billing switched on, products were created in both stores at once. If one store failed, the product created in the other was deleted, so the two stores never disagreed.
A nightly end-to-end test created a plan, waited for it to go active, subscribed and checked every price tier.
Verification with Apple and Google
The server confirmed every purchase directly with Apple or Google before granting anything.
The app sent only a purchase ID or receipt. The server fetched the purchase from the App Store Server API or the Google Play Developer API and checked Apple's signature itself.
On a first subscription, an iOS receipt was accepted only for this app's bundle ID and only if it was less than 12 hours old.
One plan ID served as the product ID in both stores and in every notification, so a viewer could not hold the same subscription on iPhone and Android at once.
One-time purchases followed the same path in the backend. Google Play purchases were acknowledged as soon as they were recorded, because Google refunds purchases left unacknowledged for three days, and were consumed only after the credit was confirmed.
Store Notifications and Paid Access
Subscription changes reached the backend as signed notifications from the stores.
Apple's App Store Server Notifications V2 passed Apple's own verifier and updated renewals, cancellations, expiries and refunds automatically. Google's notifications arrived through Google Cloud Pub/Sub, Google's messaging service.
Notifications from Apple's sandbox, its test environment, had their own endpoint. In production they updated a subscription's status without creating any earnings.
The server checked a viewer's subscription before granting access to a subscriber-only stream or replay.
Stripe Connect Payouts
Creator payouts were built on Stripe Connect, Stripe's service for platforms that pay out to many people.
Each creator had a Stripe Express account and completed identity checks on Stripe-hosted pages, so the app never handled ID documents.
Creators saw their connected bank accounts and cards by the last four digits.
A payout locked the creator's balance, withdrew the amount and sent a Stripe transfer. A failed transfer reversed the withdrawal.
A dedicated webhook service kept each Stripe request's raw body, checked the signature on it before anything else ran, and passed valid events to Kafka.
Creator Earnings Ledger
Creator earnings lived in a ledger that only ever added entries.
Balances came from saved checkpoints plus the entries recorded after them, so they stayed fast to read and fully traceable.
Each spend or withdrawal took a per-account lock in Redis (2,000 ms, 3 retries) and saved every record in one MongoDB transaction, so money could not be spent twice.
Failures were stored with their own codes, such as insufficient funds and a locked balance.
Balances and transaction history were served from a separate read copy, kept current from Kafka, so reading never competed with spending.
About 120 unit tests covered the money services.
Reliable Money Messaging
Money events moved between services through Kafka, with delivery safeguards on every money service.
Each service committed a message only after its handler finished, so a crash midway left the message to be processed again.
A message that kept failing went to that service's own dead-letter topic with its error attached, and the queue moved on.
Message formats were versioned Avro schemas with backward compatibility, so services could be upgraded one at a time.
Results Achieved
Automated App Store deployment
Creator plans passed Apple's review automatically, publishing directly under creators' names without manual console intervention.
Dynamic self-serve pricing
Creators configure their own monthly subscription tiers natively, bypassing manual App Store or Google Play console updates entirely.
Server-side receipt validation
Every subscription transaction was verified directly against Apple or Google APIs before platform access was ever granted.
Isolated sandbox telemetry
Test transactions successfully validated production state updates for QA without ever polluting live creator ledger balances.
Double-spend concurrency protection
Atomic transactions and database locks guaranteed strictly accurate creator balances during simultaneous spending and withdrawal events.
Adding Payments to Your App?
DBB Software engineers integrate store billing and payouts, and keep the money records correct.
Contact Us
"Most of our work starts with a 30-minute call where someone describes a product they're trying to ship and one part of the engineering picture they can't get around.
If that's where you are, let's set one up; I'll tell you straight whether we're the right fit.”
Mina Morkos
Business Development Manager
Want a similar outcome for your team?
Ask our AI assistant — it can pull related case studies, talk through the approach, and put you in touch with the team if you want a deeper conversation.
