Payment lifecycle
Sale, authorization, capture, void, refund, reversal and inquiry within configured provider capabilities.
ACQUIRER SOLUTION
One integration.
More possibilities.
Bring multiple acquiring providers and payment protocols behind a consistent processing model—from real-time decisions to financial completion.
ImplementedThe processing core is implemented; provider profiles, external approvals and production readiness are solution-specific.
Payment orchestrationCONCEPT VIEW
Canonical payment requestMerchant · channel · currency · intent
MERCHANTPAISA ACQUIRERThe right route.
The right route.
The right controls.
ValidateEvaluateRoute
Bank / acquirerISO 8583
Payment providerREST API
Supported railISO 20022
Consistent outcomes. Controlled recovery.
Illustrative architecture · each provider profile requires validation
THE PROCESSING FOUNDATION
Keep complexity
behind the interface.
Normalize payment intent, response meaning and recovery behavior—without erasing the rules of each provider.
Policy-based routing
Evaluate merchant, scheme, currency, channel, capability, health and priorities before provider selection.
Risk, limits & eligibility
Apply configured transaction rules and limits before financial transmission.
Idempotency & duplicates
Protect repeated requests and preserve financial intent through the supported transaction lifecycle.
Provider abstraction
Keep protocol mappings, credentials, response codes and provider behavior inside dedicated adapters.
Operational visibility
Make outcomes, attempts, provider behavior and recovery exceptions visible to authorized operators.
BUILT FOR THE DIFFICULT CASES
Uncertain response.
Controlled next step.
A timeout is not automatically a decline. When a payment may have reached a provider, recovery must preserve financial truth.
No blind rerouting after
ambiguous financial transmission.
Inspect the transmission state. Use supported inquiry or reversal. Resolve the original financial intent before considering a new attempt.
IN_DOUBT
Investigate before retrying.
The provider response is uncertain. Preserve the original intent and resolve it through the configured recovery workflow.
Request recordedTransmission assessedInquiry / resolution required
Illustrative scenario · no financial request is executed
AFTER AUTHORIZATION
Close the loop.
Not just the transaction.
Connect presentment, acknowledgement, settlement, reconciliation and payment-event accounting in a controlled financial lifecycle.
Clearing & presentment
Prepare eligible records, match authorizations, generate files and handle acknowledgements, rejects and controlled resubmission.
Original history retained
Interchange & fees
Configure versioned, effective-dated calculations from authorized provider, sponsor or scheme specifications.
No invented production rates
Settlement positions
Track gross/net positions, fees, settlement cycles, currencies, confirmations and financial exceptions.
Explicit financial state
Reconciliation & accounting
Compare clearing, sponsor/provider data and settlement results; connect outcomes to switch accounting and exception review.
Differences stay visible
Visa / Mastercard clearing readiness
The supplied marketing baseline reports internal UAT and internal pre-certification for scheme clearing. Official specification mapping and external certification remain required before production scheme use.
Review the external go-live requirementsCONNECTIVITY WITH CLEAR CONDITIONS
Different providers.
A consistent foundation.
Integrate the rails and acceptance channels your operating model requires, using validated profiles and the right external approvals.
Card-present EMV/contactless, e-commerce/3DS, stored credentials, tokenization and wallet-payment acceptance depend on the provider, market and agreed implementation.
Build your capability briefISO 8583
Traditional bank and processor host profiles.
REST APIs
Modern PSP, acquirer and processor integrations.
ISO 20022
Applicable payment rails and message profiles.
Direct / sponsored scheme access
Official onboarding, profiles, testing and approval.
IMPORTANT DISTINCTIONS
Strong architecture.
Honest boundaries.
Is MerchantPaisa officially Visa or Mastercard certified?
This site does not claim completed external scheme certification. Internal UAT and pre-certification reported in the source marketing baseline are engineering milestones, not network approvals.
Does 3-D Secure mean a payment is authorized?
No. Cardholder authentication and financial authorization are separate stages. A 3DS result does not itself authorize funds or guarantee acceptance.
Are all payment wallets and local schemes available?
No universal availability is claimed. Wallet acceptance, local schemes, account updater and network tokens require provider compatibility, enrollment, agreed scope and any necessary external approval.
Is the switch ledger a complete accounting system?
The ledger scope is payment-event and switch accounting. It is not presented as a replacement for corporate accounting, an ERP or jurisdiction-specific financial reporting.
LET’S BUILD TOGETHER
Make your acquiring
architecture work harder.
Let’s map your providers, financial lifecycle and operational requirements to a connected processing model.