Building Fintech Apps for Payments, Wallets and Credit Products
In fintech, writing the product is only half the job; the hard part is proving under which permission the money moved, and from which account to which account. For a newly launched payments venture, an app cannot go live without KYC, reconciliation, dispute handling and an audit trail. This page explains those layers.
How many separate apps does this need?
-
01
End-user mobile app (iOS + Android)
Sign-up and KYC flow, ID document plus selfie verification, wallet balance, top-ups and withdrawals, transfers by IBAN or QR code, saved cards, spending history, dispute submission and real-time transaction notifications.
-
02
Merchant / dealer app
The screen where the merchant takes payment: QR code generation, payment by link, end-of-day turnover, settlement and value-date tracking, refunds and partial refunds, and permission separation by device and staff member.
-
03
Operations and compliance admin panel
KYC queue and manual approval, suspicious activity alerts, limit and risk rules, account freezing, dispute files, reconciliation discrepancies, and retrospective transaction search for MASAK (Turkey's financial crimes investigation board) reporting.
-
04
Integration portal
A web interface where the merchant sees its API key, webhook address, test environment and signature verification documentation; the status of the test scenarios required before going live is tracked here.
What the app includes
- Account opening by reading the chip in the ID card over NFC
- Collecting payment via static and dynamic QR codes
- Name-to-IBAN match check before the transfer is sent
- Separate display of pending authorisations and settled transactions
- Freezing and unfreezing the card with one tap
- Monthly limit and remaining quota indicator
- Recurring payment mandates with a self-service cancellation screen
- Value-date and payout calendar for the merchant
- Partial refunds shown as a chain of reversing ledger entries
- Statement export as PDF and CSV for bookkeeping
- Webhook replay and a log of signature verification results
- Creating payment links that expire after a set time
State of the sector
In fintech the pressure comes from two directions: on one side, banks' own apps offer basic transfers and QR payments for free; on the other, off-the-shelf infrastructure providers push similar products to market quickly. In that environment, differentiation comes from solving the money flow of a narrow audience extremely well: end-of-day settlement for small merchants, supplier payments in one industry, the instalment needs of a specific group. A venture without an app can only describe its product; users will not hand over their money without seeing the screens, and showing a working product also makes the licensing process easier.
Metrics that matter here
- KYC completion rate (from application to approval) — As the verification step is simplified and automatic NFC reading is added, fewer applications are abandoned halfway and more users get approved.
- Payment success rate (including 3D Secure) — Retries, timeout handling and failover to a second provider directly recover transactions that would otherwise fail.
- Number of reconciliation discrepancies and time to close them — Automated statement comparison catches a discrepancy on the day it occurs rather than weeks later, reducing operational load and losses.
- Dispute and fraud amounts as a share of transaction volume — Device fingerprinting, risk rules and the chain of evidence reduce the amounts lost in disputes and held in blocks.
Common mistakes in this sector
- Keeping the balance as a single number in the database Updating a balance column directly for the sake of speed is the most common mistake. Two concurrent transactions corrupt the amount, and fixing it retrospectively becomes impossible. The correct approach is to derive the balance as the sum of immutable movement records.
- Leaving the compliance and operations panel until last Once the mobile app is finished and launch approaches, the team realises there are no screens for suspicious activity, account freezing or disputes. The product cannot go live without them; the panel must be planned at the same time as the mobile app.
- Locking yourself into a single payment provider Writing the whole flow around one provider's fields means all collections stop when that provider has an outage. The payment layer should be abstracted from the start, so adding a second provider is a configuration matter rather than a new project.
- Mixing the test environment with live money flows Testing with the same keys and triggering a real charge, then waiting weeks for the refund, happens often. Test and live keys, databases and webhook addresses must be fully separated, and live keys should never sit on a developer's machine.
Regulation and compliance
Any model that holds or intermediates funds requires a payment institution or electronic money institution licence under Turkish Law No. 6493; operating without one carries severe sanctions and can also be requested as documentation during store submission. MASAK (Turkey's financial crimes investigation board) obligations make customer due diligence (KYC), identity verification, suspicious activity reporting and retention of transaction records for the prescribed period mandatory. ID images, selfies and financial movements are data that require particular care under KVKK (Turkey's data protection law, aligned with GDPR): the privacy notice, explicit consent, retention periods and use of servers abroad must all be settled up front. Issuing e-Fatura / e-Arşiv documents (Turkey's mandatory e-invoicing system) for commission and service fees is a separate obligation on the GİB (Turkish Revenue Administration) side.
The real challenges in this sector
-
The in-app balance and the bank account can never be read from a single source
The balance shown to the user comes from the app's own ledger, while the money moves through the provider's pooled account. The gap between the two lets a customer spend the same amount twice. The fix: a ledger that records every movement as a double-entry, append-only record, a balance derived as the sum of those records, automatic end-of-day reconciliation against the provider statement, and a discrepancy report.
-
The “where did the money go” question when a payment call times out
When the mobile network drops, it is unclear whether the request reached the provider; if the user retries, a double charge appears. The fix: an idempotency key generated on the client for every payment request, a server-side lock that returns a single result for the same key, a background job that queries the provider and finalises the transaction when the outcome is uncertain, and a screen that honestly shows the user a pending state.
-
Running liveness and identity checks on the device during KYC
If the ID document and selfie can be uploaded from the photo gallery, the door opens to forged documents. The fix: a capture screen that works only from a live camera feed, with screenshots and gallery input disabled; NFC chip reading of ID cards on supported devices; verification that the first name, surname and national ID number match via MERNIS/KPS (Turkey's national population and identity registry); and applications that cannot be verified automatically going into a manual review queue instead of being auto-rejected.
-
Proving device and session security inside the app
Malicious software on a rooted or jailbroken device can read the PIN and OTP screens. The fix: root and emulator detection, screenshots and screen recording disabled on sensitive screens, hardware-backed key storage in the Keychain/Keystore, certificate pinning, and a risk rule that temporarily lowers transaction limits when the device changes.
-
Running disputes and refunds with a chain of evidence
Card disputes have strict deadlines; if no evidence is submitted, the amount is clawed back. The fix: storing the device ID, IP address, timestamp and approval steps for every transaction in tamper-proof form; a workflow that gathers this evidence package on a single screen when a dispute is opened, with a deadline countdown; and refunds posted as reversing entries in the ledger and reflected in reconciliation the same day.
Required integrations
- 3D Secure flows via virtual POS and payment providers (iyzico, PayTR, Param and Craftgate, Turkish payment providers)
- Bank pooled-account integration: FAST (Turkey's instant payment system), EFT and wire transfer notifications, plus end-of-day statement retrieval
- Identity and address verification through MERNIS/KPS (Turkey's national identity registry)
- e-Fatura / e-Arşiv integration (Turkey's mandatory e-invoicing system) for commission and service fee invoices, compliant with GİB (Turkish Revenue Administration)
- SMS OTP and push-based second-factor authentication provider
- MASAK sanctions and watchlist screening plus risk scoring services
Who this page is for
-
A newly founded payment start-up whose licence application is still in progress
The right scope is a first version that holds no funds itself but shows the whole flow: KYC, ledger and console working, with money moving over a licensed institution's rails. When the permission arrives, only the provider layer is switched on.
-
A regional distributor with a dealer or shopkeeper network
The need here is not an open wallet but a closed-loop balance: the dealer's current account, prepaid top-ups, offsetting at order time and end-of-day payouts. No licence burden arises; the priority is integration and reconciliation with the ERP and current accounts.
-
A niche venture offering a financial product to a narrow audience
A team focused on a single flow, such as building-association dues, a campus card or supplier payments, keeps the scope narrow: the rules, limits and reports of that one flow work flawlessly. Card and credit modules move to later phases, and plain transfers come last, since banks already offer them free.
A phased plan that splits the budget
-
1
Phase 1 — One money flow in a closed wallet 9-12 hafta
Delivers sign-up and KYC, a double-entry wallet ledger, top-up through a single payment provider, spending or transfer, transaction history and the core of the compliance console. It can go live on its own, because every path money takes in or out is closed by reconciliation; later modules sit on top of this ledger.
-
2
Phase 2 — Merchant collection and dispute handling 7-9 hafta
Adds QR and payment-link collection, end-of-day payouts with value-date tracking, partial refunds, dispute files with their evidence package, and a second payment provider. The order is deliberate: refund and dispute rules can only be designed sensibly once real transaction volume exists, so they are written against Phase 1 data.
-
3
Phase 3 — Risk rules, limit products and the integration portal 6-8 hafta
Brings device-fingerprint risk scoring, sanctions-list screening, product modules such as instalments or credit limits, plus an API key and sandbox portal for outside developers. It comes last because risk rules can only be tuned against your own transaction data; set earlier, they block legitimate users.
Typical scope and timeline
A first release typically covers: native iOS and Android apps, a KYC and identity verification flow, a wallet ledger, top-ups with 3D Secure through a single payment provider, transfers, transaction history, dispute submission, an operations and compliance panel, an end-of-day reconciliation report, security hardening with penetration test fixes, and store submission.
Estimated timeline: 16-24 weeks
Off-the-shelf or custom build?
| Topic | Off-the-shelf | Custom build |
|---|---|---|
| Licence and compliance responsibility | With a licensed provider's ready-made solution, much of the compliance burden sits with them; without your own permission this is the most realistic way to start. | Custom development shapes the KYC queue, suspicious-activity reporting and retention periods around your own processes, but the obligation is then yours to carry. |
| Independence from the payment provider | A packaged product usually ships with its own provider; setup is short and the certification and 3D Secure flow are already tested. | Custom work abstracts the payment layer, so adding a second provider or switching one during fee negotiations does not mean a rewrite. |
| Cost structure | A monthly subscription plus a share per transaction keeps the entry cost low; while volume is small, the packaged option is clearly cheaper. | Custom development is a one-off investment; as volume grows the per-transaction share disappears, and the break-even point is set by that volume. |
| Ownership of the ledger and transaction data | In a packaged solution the records live in the provider's system; the reporting screens come ready and cover day-to-day needs in most cases. | With custom development the ledger sits in your own database, so retrospective searches for regulators, handing raw data to an auditor and migrating away from a provider stay in your hands. |
Sector glossary
- Value date (valör)
- Not the date money appears on the account but the date it actually becomes usable. On a merchant screen it explains why turnover and withdrawable balance differ.
- Authorisation hold
- Blocking an amount on the card without capturing it. It shows as pending, then is either captured or released when it expires; mixing the two in one list generates support calls.
- Chargeback
- The cardholder reversing a transaction through their bank. If evidence is not filed in time the amount is taken back from the merchant, which is why evidence is collected at transaction time, not when the dispute opens.
- Pooled account
- The single bank account where every user's money physically sits. Who owns how much exists only in the app's ledger, so the pool and the ledger total must match every single day.
- Idempotency key
- A unique code that makes a payment request run once even if it is sent again. It is what stops a double charge when the user taps twice or the connection drops.
Frequently asked questions
Let us talk about your project
A free 30-minute call to scope it out, then an itemised quote within 48 hours.
Get a Free QuoteThis page explains the problems an app must solve in this sector. We share references and comparable projects during the call.