DEV Community: Vaibhav Shakya

Designing a Secure Transaction Lifecycle: From Intent Creation to Settlement Confirmation

Vaibhav Shakya — Tue, 21 Jul 2026 06:11:14 +0000

Designing a Secure Transaction Lifecycle: From Intent Creation to Settlement Confirmation

A payment transaction is not a single API call. It is a distributed workflow across the customer device, backend, external payment systems, message infrastructure, ledger, and reconciliation process.

These components do not share one transaction boundary. They may time out independently, deliver duplicate or delayed events, or temporarily disagree about the result.

Begin With a Server-Owned Intent

The mobile application should request a payment, not determine its financial truth.

The backend retrieves the authoritative order, calculates the amount from server-controlled data, verifies ownership and eligibility, and creates a stable transaction intent.

Individual external interactions should be stored as separate attempts. This preserves the history of unresolved outcomes, declines, retries, and eventual capture.

Make Retries Idempotent

A request may begin or complete processing even when its response is lost. If the customer retries with a new operation identity, the platform can create a duplicate charge.

The client should reuse the same operation key for the same logical action. The backend should bind that key to the authenticated principal, operation, and canonical request fingerprint.

Durable uniqueness is essential because concurrent requests can reach different API instances. Application-level checks alone do not close that race.

Use an Explicit State Machine

Transaction status should be governed by validated transitions rather than arbitrary updates.

A lifecycle may include CREATED, PROCESSING, REQUIRES_CUSTOMER_ACTION, AUTHORIZED, CAPTURED, SETTLEMENT_PENDING, and SETTLED.

The exact states depend on the payment rail. Each transition should preserve its source, previous state, timestamp, correlation identifier, and reason.

Keep the Mobile Client Outside the Trust Boundary

Mobile clients can initiate transactions and present results, but they should not declare financial success.

Redirects, deep links, and SDK callbacks are user-experience signals. The backend should determine state through authenticated external events, server-to-server queries, or other appropriate evidence.

Integrity and application-attestation signals can strengthen risk decisions, but their coverage and behaviour vary. They do not prove customer identity or eliminate fraud.

Authenticate and Deduplicate Webhooks

External events should be authenticated, validated, durably recorded, and processed idempotently.

Deduplicating an event identifier prevents repeated handling of that event object, but separate events may still describe the same business transition. State guards and business-level idempotency remain necessary.

For reliable internal propagation, write the state change and outbox record in the same local database transaction. Downstream consumers must still tolerate repeated delivery.

Separate Transaction State From the Ledger

A transaction record describes operational progress. A ledger records how balances changed.

Ledger postings should be balanced and append-oriented. Fees, refunds, reversals, chargebacks, and settlements should create additional postings instead of rewriting financial history.

Capture Is Not Settlement

Authorization, capture, settlement, and payout describe different facts, although some payment methods may combine or hide particular stages.

Settlement should be confirmed using the evidence available for the applicable payment rail. Reconciliation should compare identifiers, amounts, currency, fees, and merchant ownership.

When values disagree, preserve both sides and create an exception instead of forcing the internal record to match.

Design for Ambiguous Outcomes

Assume that an external system can succeed while the backend times out, an event can arrive more than once, and fulfilment can fail after capture.

Correctness comes from stable identifiers, durable idempotency, controlled transitions, balanced ledger postings, and reconciliation—not from assuming every request has a clean response.

Practical Takeaway

A secure transaction lifecycle needs:

A server-owned intent
Separate payment attempts
Durable idempotency
Explicit state transitions
Authenticated asynchronous events
Idempotent consumers
Balanced, append-oriented ledger postings
Settlement reconciliation
Complete audit and repair trails

Read the complete Medium article: https://medium.com/@vaibhav.shakya786/designing-a-secure-transaction-lifecycle-from-intent-creation-to-settlement-confirmation-272666741fa9

API Contract Governance for Mobile Platforms

Vaibhav Shakya — Mon, 20 Jul 2026 04:35:19 +0000

Mobile API compatibility is not determined by the latest app release. It is shaped by every supported client that can still reach production—including older binaries, queued operations, and users who update slowly.

Adding /v2 does not automatically isolate the previous contract. Both versions may still share databases, services, caches, background jobs, and downstream integrations.

For example:

Changing a field from an empty string to null can break an older client with strict decoding.
Changing a business failure from HTTP 200 to 422 can send older clients into a generic network-error flow.

Safer API evolution requires additive changes, supported-client testing, version-specific telemetry, backend execution controls, measured deprecation, and data-compatible rollback.

A mobile feature flag can hide a screen, but it cannot reliably stop older binaries, queued operations, or replayed requests. Sensitive operations must still be controlled by the backend.

Rollback must restore behaviour across code, data, events, jobs, and accepted operations—not merely redeploy an older backend image.

Read the complete article on Medium

Cross-Platform Mobile Architecture Is a Boundary Decision

Vaibhav Shakya — Tue, 14 Jul 2026 05:45:50 +0000

Cross-platform mobile architecture is often reduced to one question:

Which framework lets us share the most code?

At scale, that is usually the wrong metric.

Native, Flutter, React Native, and Kotlin Multiplatform place the shared boundary at different layers—UI, rendering, application logic, domain behaviour, and platform integration.

The more important decision is determining which behaviour must remain consistent and which capabilities require independent Android and iOS control.

A shared implementation still depends on platform lifecycles, native SDKs, release pipelines, backend compatibility, and production observability.

The largest risks are rarely visible in a prototype. They emerge through plugin ownership, state restoration, background execution, dependency upgrades, asymmetric rollouts, and unclear responsibility across shared and native layers.

The goal is not maximum code reuse.

It is to share behaviour where inconsistency is costly while retaining platform control where operational differences matter.

Read the complete article and practical architecture checklist:

Cross-Platform Mobile Architecture: Native, Flutter, React Native, and Kotlin Multiplatform Trade-Offs at Scale

Designing Feature Flags and Kill Switches for Mobile FinTech

Vaibhav Shakya — Mon, 13 Jul 2026 09:09:37 +0000

Feature flags are often introduced as interface controls: expose a journey to a small cohort, observe it, and gradually increase the rollout.

For mobile FinTech, that is only the outermost layer.

A mobile binary may remain installed after further distribution is paused. The application may use embedded or cached configuration, remain offline, resume an existing screen, or submit work after the backend’s operational state has changed. Hiding an interface therefore reduces exposure, but it does not authorize or disable the underlying financial operation.

A safer design separates presentation from execution authority.

Mobile flags control visibility and journey entry. The backend independently decides whether an operation is permitted. Integration adapters control traffic to individual providers, while asynchronous consumers need explicit rules for new work, retries, pausing and draining.

Operational controls also need more expressive states than one Boolean. A system may need to stop new transactions while retaining status checks, reconciliation, support visibility and recovery processing. States such as DISABLED, READ_ONLY, LIMITED, DEGRADED and DRAINING can represent those boundaries, provided the state model remains small and tested.

Configuration freshness must be treated as part of the contract. Mobile delivery depends on connectivity, caching, throttling, lifecycle and activation behaviour. Backend propagation can also be temporarily inconsistent. Critical execution must therefore remain server-authoritative, with explicit fallback behaviour when current policy cannot be established.

Retries and in-flight work require separate handling. An idempotency key alone is not a complete guarantee; the operation also needs stable identity, atomic duplicate handling, parameter validation and sufficient retention. Queued work must remain safe under duplicate delivery and policy changes.

The complete article covers:

Mobile and backend trust boundaries
Runtime configuration flow
Stateful kill switches
Version-aware backend policy
Stable rollout cohorts
Idempotent financial operations
Queue and retry controls
Observability and governance
Failure and recovery behaviour
A practical UPI-routing scenario

Read the Medium article: Designing Feature Flags and Kill Switches for Mobile FinTech: Safe Rollouts Under Production Risk

Mobile Observability Architecture: Connecting Crashes, Logs, Traces, API Failures, and Business Events

Vaibhav Shakya — Fri, 19 Jun 2026 04:43:18 +0000

Mobile observability should not start only at the crash.

A crash report can show where the app failed, but it may not explain what the user was doing, which API failed before it, whether the backend completed the transaction, or where the business journey actually broke.

For critical flows like payment, KYC, onboarding, booking, or subscription activation, observability should start at the user action.

The system should connect:

crashes
logs
traces
API failures
release metadata
business events

The important part is shared context.

A request ID, session ID, flow ID, app version, screen name, and release channel can help mobile, backend, platform, and product teams reconstruct the same incident from different angles.

Mobile telemetry is always partial and delayed. Devices go offline, apps are killed, networks change, and users retry actions.

That is why observability should not depend on one dashboard.

It should help answer:

Where did the user journey break, what system boundary caused it, and what business outcome was affected?

Full article:

https://medium.com/@vaibhav.shakya786/mobile-observability-architecture-connecting-crashes-logs-traces-api-failures-and-business-b9e7d09198df

Designing KYC State Machines for FinTech: From Onboarding Chaos to Governed User Lifecycle

Vaibhav Shakya — Thu, 18 Jun 2026 04:57:00 +0000

Designing KYC State Machines for FinTech

KYC onboarding in FinTech usually does not fail because one screen is broken.

It fails when the user lifecycle is not governed properly.

PAN may be verified, GST may be pending, Aadhaar may timeout, email may complete from another device, and payment may succeed before the backend has finalized the user’s lifecycle state.

The architectural shift

Treat KYC as a backend-owned state machine, not a frontend checklist.

The app should guide the user, but the backend should own:

lifecycle truth
allowed transitions
audit logs
retries
access control

A good KYC design separates user lifecycle state from verification status. It makes transitions explicit, idempotent, auditable, and easier to recover under real production failure.

Read the full article on Medium:

https://medium.com/@vaibhav.shakya786/designing-kyc-state-machines-for-fintech-from-onboarding-chaos-to-governed-user-lifecycle-674589f7c47b

Why Backend Trust in Mobile Clients Breaks Security Architecture

Vaibhav Shakya — Wed, 17 Jun 2026 04:35:45 +0000

Mobile apps can guide users, but they should not authorize system truth. 🔍

In mobile systems, the app runs on a device the backend does not fully control. That means backend systems should not blindly trust values sent from the client, even when the request comes from the official app.

Fields like pricing, ownership, eligibility, KYC state, refund status, retry safety, and risk decisions should be derived or verified server-side.

The better model is simple:

The client describes intent.

The backend verifies truth.

Before committing anything irreversible, the backend should validate:

user authentication
object ownership
permissions
lifecycle state
idempotency
replay safety
risk context

This becomes especially important in fintech, mobile security, and API-driven systems where a trusted-looking mobile request can still carry manipulated or stale state.

I wrote the full article here:

medium.com

Defense-in-Depth for Mobile FinTech: Why No Single Security Control Is Enough

Vaibhav Shakya — Mon, 15 Jun 2026 04:06:33 +0000

Mobile FinTech Security Is Not One Control

Mobile FinTech security should not depend on a single control.

Pinning, root checks, biometrics, app integrity, and encryption are useful signals — but they are not the final authority.

Real trust comes from layered backend decisions across user, device, session, risk, idempotency, and transaction context.

Read the full article here:

https://medium.com/@vaibhav.shakya786/defense-in-depth-for-mobile-fintech-why-no-single-security-control-is-enough-0cbf55035f66

Mobile Risk Signal Architecture: Combining Device, Network, App, User, and Transaction Context

Vaibhav Shakya — Fri, 12 Jun 2026 04:47:38 +0000

Mobile risk is not a single SDK, root check, attestation result, or fraud rule. ⚙️

In real production systems, risk comes from the combination of device, app, network, user, session, and transaction context.

A clean device can still perform a risky action.

A suspicious device does not always mean the user is fraudulent.

The architectural shift is simple but important:

Mobile should collect signals, but the backend should own the decision.

Sensitive actions like payout, bank account change, password reset, refund, settlement, or beneficiary addition need action-specific risk evaluation.

A strong system does not only block.

It can allow, step up, delay, limit, hold for review, or block depending on context. It also needs freshness checks, idempotency, reason codes, and graceful degradation when signals are incomplete or temporarily unavailable. 🔍

I wrote a detailed article on designing mobile risk signal architecture across Android, iOS, backend, and transaction systems.

Read the full Medium article here:

https://medium.com/@vaibhav.shakya786/mobile-risk-signal-architecture-combining-device-network-app-user-and-transaction-context-f41ea300cf9b

Payment Failure Architecture: Designing Retry, Reversal, Refund, Settlement, and Reconciliation Flows

Vaibhav Shakya — Thu, 11 Jun 2026 04:22:18 +0000

Payment failures are rarely just “failed payments” ⚙️

A customer may see money debited.

The app may show timeout.

The backend may keep the transaction pending.

The payment processor may confirm success a few minutes later.

All systems can be correct from their own boundary, but the product experience still breaks.

The real architecture problem

The mistake is treating payment as a single success/failed flag.

In real systems, these are separate flows:

Retry
Reversal
Refund
Settlement
Reconciliation

Each flow has different owners, timelines, risks, audit requirements, and customer impact.

What strong payment systems usually need

A production-grade payment architecture should include:

Durable payment attempt IDs
Idempotent retry handling
Controlled state transitions
Event deduplication
Pending verification states
Append-only ledger entries
Settlement mapping
Reconciliation jobs
Support-visible operational status

The goal is not only to process payments.

The goal is to explain what happened when money moved, confirmation was delayed, refund failed, or settlement did not match.

Mobile should not decide payment truth

The mobile app should not be the final source of truth for payment completion.

It should recover safely from:

Timeout
App switch
SDK return
Browser return
Delayed callbacks
Network loss

After returning from a payment flow, the app should ask the backend for the authoritative payment status instead of assuming success or failure locally.

Why this matters

A timeout is not always a failed payment.

A successful payment is not always settled.

A refund initiated event does not always mean money has reached the customer.

A callback should not directly overwrite business state without validation.

That is the difference between integrating a payment gateway and designing a payment system.

Read the full article

I wrote a detailed Medium article on designing payment failure architecture across mobile, backend, platform, finance, and support boundaries.

👉 Read the full article here:
https://medium.com/@vaibhav.shakya786/payment-failure-architecture-designing-retry-reversal-refund-settlement-and-reconciliation-f5556de08038

Reference Architecture for a Secure, Scalable, and Audit-Ready FinTech Mobile Platform

Vaibhav Shakya — Tue, 09 Jun 2026 05:49:05 +0000

A FinTech Mobile Platform Is a Distributed Trust System

A FinTech mobile platform is not just an app connected to APIs.

It is a distributed trust system where the mobile app, backend, platform layer, data layer, and audit layer must work together.

Security and reliability do not come from one control alone.

They come from layered decisions across mobile signals, backend authorization, risk checks, idempotent workflows, runtime controls, and audit trails.

The mobile app can provide useful signals, but business truth must remain server-side.

Autoscaling can help with traffic, but it does not automatically protect financial correctness.

Certificate pinning, root detection, token-based authentication, and rate limits are useful controls, but none of them are complete architectures by themselves.

I wrote the full article here:

Reference Architecture for a Secure, Scalable, and Audit-Ready FinTech Mobile Platform

Your Backend Trusts Your App Too Much

Vaibhav Shakya — Tue, 05 May 2026 04:37:01 +0000

Most systems assume:

“Requests coming from our app are safe.”

That assumption breaks quickly.

Mobile apps handle validation, flows, and restrictions — but the client environment is controllable. Requests can be modified, replayed, or triggered outside the UI.

The real issue isn’t missing validation — it’s misplaced trust.

What goes wrong

Client-side validation gets bypassed
Flows are executed out of sequence
Parameters are tampered
Requests are replayed

Example

❌ Vulnerable:

if (req.isKycVerified) {
    generateLink();
}

Client controls this flag.

✅ Correct:

User user = repo.find(req.userId);

if (user.getKycStatus() == VERIFIED) {

    generateLink();

}

What to fix

Backend must be the source of truth
Validate all critical data server-side
Enforce flows on backend
Add idempotency for sensitive operations

Key takeaway

UI constraints are not security controls.

👉 Full breakdown on Medium
https://medium.com/@vaibhav.shakya786/your-backend-trusts-your-app-too-much-heres-how-attackers-abuse-that-670af5c9b1a3