Developing a Crowdfunding Mobile Application
A few years ago, one of our crowdfunding platforms encountered a problem: in the last hour of a campaign, the number of concurrent backing requests increased tenfold, and the database couldn't handle the transactions—some payments ended up stuck in pending status, and backers experienced double charges. After an audit, we rewrote the authorization mechanism and added sharding by project_id. That mistake cost the client significant reputational damage—and helped us refine the architecture we now use across all projects. In this article, we'll examine the key components that turn an MVP into a production-grade platform: from escrow models to fast payouts. We draw on experience from 50+ fintech and marketplace solutions, over 8 years in mobile development, and a track record of delivering 50+ projects worldwide.
How to Implement Reliable Conditional Fund Deduction?
All-or-Nothing (AoN) — funds are deducted only when the goal is reached. If the campaign doesn't meet its target, all payments are refunded. Implementation: on backing, we make an authorization hold on the card (funds are frozen but not charged). On campaign success — capture, on failure — void. Our sharded database architecture handles 10x more concurrent transactions than a standard monolithic setup.
# Stripe: create PaymentIntent with capture_method=manual
import stripe
def back_project(user_id: str, project_id: str, amount: int, reward_tier_id: str) -> dict:
payment_intent = stripe.PaymentIntent.create(
amount=amount,
currency="usd",
capture_method="manual", # don't charge immediately
metadata={
"user_id": user_id,
"project_id": project_id,
"reward_tier_id": reward_tier_id
},
confirm=False # confirm on client side
)
return {"client_secret": payment_intent.client_secret}
def capture_all_backers(project_id: str):
"""Called when campaign finishes successfully"""
backers = db.get_backers(project_id, status="authorized")
for backer in backers:
stripe.PaymentIntent.capture(backer.payment_intent_id)
db.update_backer_status(backer.id, "captured")
def refund_all_backers(project_id: str):
"""Called when campaign fails"""
backers = db.get_backers(project_id, status="authorized")
for backer in backers:
stripe.PaymentIntent.cancel(backer.payment_intent_id)
db.update_backer_status(backer.id, "cancelled")
Problem: the authorization on the card lasts a limited time — for Stripe it's 7 days for most cards, maximum 31 daysStripe Documentation: "Authorization holds". Campaigns longer than 30 days can't hold the authorization for the whole period. Solution: charge immediately (Keep-it-All model) or re-authorize shortly before expiry.
Keep-it-All (KiA) — funds are deducted immediately on backing, regardless of goal achievement. Technically simpler, but less attractive for backers. Popular for charitable and creative projects. According to Statista, AoN campaigns raise on average 40% more funds than KiA, so for commercial projects we recommend the former model. Success rate for AoN campaigns is around 80% for well-prepared projects.
| Parameter | All-or-Nothing | Keep-it-All |
|---|---|---|
| Charge moment | On campaign success | Immediately on backing |
| Backer trust | High | Medium |
| Implementation complexity | High (authorization, timeouts) | Low |
| Suitable for | Commercial projects | Charity, creative |
Why is AoN preferable for large projects?
According to Stripe, about 70% of successful crowdfunding campaigns use AoN. Backers feel more confident knowing their money won't be lost if the goal isn't reached.Reward Tiers
Each project offers several tiers: "Support" for $10, "Early Access" for $50, "Exclusive Bundle" for $200. Each tier has a limited number of slots and current occupancy.
// iOS: reward tier selection view
struct RewardTierView: View {
let tier: RewardTier
let onSelect: () -> Void
var body: some View {
VStack(alignment: .leading, spacing: 8) {
HStack {
Text("$\(tier.amount)")
.font(.title2.bold())
Spacer()
if let limit = tier.backerLimit {
Text("\(tier.backerCount)/\(limit) backed")
.font(.caption)
.foregroundColor(tier.isSoldOut ? .red : .secondary)
}
}
Text(tier.title).font(.headline)
Text(tier.description).font(.body).foregroundColor(.secondary)
if let estimatedDelivery = tier.estimatedDelivery {
Label("Delivery: \(estimatedDelivery)", systemImage: "shippingbox")
.font(.caption)
}
Button(tier.isSoldOut ? "Sold Out" : "Select Tier") {
if !tier.isSoldOut { onSelect() }
}
.disabled(tier.isSoldOut)
}
.padding()
.background(.regularMaterial)
.clipShape(RoundedRectangle(cornerRadius: 12))
}
}
Limited slots require pessimistic locking on the server: when processing a backing, we lock the reward_tier row to check and decrement the counter in a single transaction.
Campaign Progress and Social Mechanics
The project page is the central content. A progress bar showing funds raised, a countdown to the campaign end, an update feed from the author, and backer comments.
Technically, the most loaded moment: the last day of the campaign. All backers check progress simultaneously. WebSocket for real-time updates or aggressive polling (every 10 seconds in the final hours) — with CDN caching.
// Android: WebSocket for live progress updates
class CampaignProgressViewModel(
private val campaignId: String,
private val wsClient: WebSocketClient
) : ViewModel() {
val progress = MutableStateFlow<CampaignProgress?>(null)
init {
wsClient.connect("wss://api.yourplatform.com/campaigns/$campaignId/live")
viewModelScope.launch {
wsClient.messages.collect { message ->
val update = json.decodeFromString<CampaignProgressUpdate>(message)
progress.value = update.progress
}
}
}
override fun onCleared() {
wsClient.disconnect()
}
}
Project Updates and Backer Communication
The author publishes updates on progress. Backers receive push notifications for each new update. Segmentation: notify only those who backed that specific project. Open rates for targeted push notifications average 25%.
FCM topic-based messaging isn't suitable for this — we need targeted broadcasts via a server-side recipient list. For each project, we store a list of backers' device_tokens.
How Does Author Verification (KYC) Work and Why Is It Critical?
Public fundraising attracts fraudulent projects. Basic protection:
- Manual moderation of new projects before publication — 90% of projects pass within 24 hours.
- Author identity verification via KYC (passport + selfie) — mandatory for fund withdrawal. This reduces fraudulent submissions by 70% compared to platforms without identity checks.
- Automatic withdrawal limits until KYC is confirmed.
The verification process step by step:
- Author fills in their profile in the app.
- Clicks "Verify" — the system generates an accessToken for the KYC provider.
- A native SDK (Sumsub, Veriff, or Onfido) opens, where the author takes a photo of their passport and a selfie.
- The SDK sends data to the provider, which checks the documents and returns a status.
- If the status is
approved, the author can request withdrawal. Ifrejected, they are sent for re-verification with a comment.
Integration with KYC providers: Sumsub, Veriff, Onfido. The mobile app initiates KYC via the provider's SDK — the entire process is in native UI. We guarantee data security — all SDKs are certified.
// iOS: Sumsub KYC flow
import IdensicMobileSDK
let sdk = SNSMobileSDK.build(
accessToken: kycAccessToken
)
.withHandlers(
onStatusDidChange: { [weak self] sdk, prevStatus in
if sdk.mainState == .approved {
self?.onKYCApproved()
}
},
onEvent: { sdk, event in }
)
.assemble()
sdk.present(from: self)
Withdrawals for Authors
After a successful campaign, the author wants to access the money. Withdrawal flow:
- KYC passed → can request withdrawal
- Platform deducts its commission (typically 6–8%)
- The remainder is withdrawn via Stripe Connect (payout to a bank account) or international transfer
Stripe Connect is the standard for marketplaces with payouts. Each author is a separate Connected Account.
What Our Work Includes
- Requirements analysis and architectural design
- Development for iOS (Swift 5.9+, SwiftUI) and Android (Kotlin, Jetpack Compose)
- Integration of payments (Stripe, Braintree) and KYC providers
- Configuration of push notifications (FCM/APNs), deep linking, App Tracking Transparency
- Content moderation and anti-fraud algorithms
- Deployment to App Store and Google Play, testing and support
What You Get (Deliverables)
- Technical documentation (API specs, architecture diagrams)
- Full source code with CI/CD pipelines
- Admin panel for project moderation and analytics
- Training for moderators on using the panel
- Post-launch support for 3 months, including bug fixes and performance monitoring
Development Timeline for a Crowdfunding Mobile App
| Scope | Duration |
|---|---|
| Basic version: project browsing, backing, payment, history | 6–8 weeks |
| Author dashboard: project creation, updates, analytics | +3–4 weeks |
| All-or-Nothing with escrow and automatic capture/refund | +2 weeks |
| KYC and Stripe Connect payout | +2–3 weeks |
A full turnkey solution including all features typically takes 12–16 weeks. Development cost for a basic MVP starts at $75,000. We provide a free estimate after analyzing your requirements.
With 8+ years of experience and 50+ fintech projects delivered, our team ensures robust, scalable solutions. Contact us for a free estimate and timeline — we offer end-to-end development, from architecture to deployment, and handle your project turnkey.