Manage payments.
Understand settlements.
Serve your customers.

• Maintain permitted legal, trading and business-contact details within your own merchant profile.
• Submit required KYB documents and track review progress, missing information and outstanding requirements.
• Review product enablement and approved settlement details alongside your onboarding progress.

Your setup Submission is not approval. Authorized reviewers decide KYB, risk acceptance, product eligibility and activation; merchants cannot self-approve.

• Use the implemented Merchant 360 workspace to connect permitted business, payment and operational views.
• Review transaction outcomes, refund references, settlement information and recent activity from available sources.
• Navigate store-level records and keep monetary totals separated by currency; restricted or unavailable panels remain explicit.

Your setup Available panels depend on your role and connected sources. A consolidated view is not a guarantee of real-time data or access to every underlying action.

• Maintain store and branch records where your merchant role permits.
• View assigned merchant and terminal references, plus associated device records.
• Follow location-linked payment activity and supported reporting within your authorized business scope.

Your setup Assignment visibility is not a certified terminal-management service. Device health, remote provisioning, software updates and remote control require separate confirmation.

• Prepare checkout sessions with an amount, currency, expiry and configured return or cancellation references.
• Review eligible payment methods and payment attempts for the enabled channel and market.
• Connect status-callback records and applicable authentication steps to the checkout lifecycle.

Your setup Session management is implemented; the customer-facing hosted journey and live API acceptance must be confirmed for your deployment. Schemes, currencies and 3-D Secure depend on provider support, enrollment and approvals.

• Organize POS/device associations and payment records by merchant and store.
• Manage supported static or dynamic QR collection requests, with amount, currency and request status where applicable.
• Trace a collection request to recorded transactions and receipt references when those sources are connected.

Your setup Configuration and recorded activity do not prove live contactless acceptance. Provider, device and scheme readiness are separate gates.

• Apple Pay acceptance needs a supported provider, device, market, token arrangement and required approvals.
• Google Pay acceptance needs its own supported provider, device, market and token configuration.
• Samsung Pay acceptance must be confirmed independently for the provider, device and market.
• Saved payment-reference and consent records support configured card-on-file journeys; they are separate from customer stored-value balances.

Your setup Individual wallet acceptance is availability to confirm, with applicable external certification dependencies. Accepting a wallet payment is not issuing a card, a wallet balance or a bank account.

• Prepare an invoice-linked request with an amount, currency, expiry and enabled payment methods.
• Keep the underlying invoice description and customer reference connected to the request; additional order linkage depends on the source.
• Review generated link and QR references, active or expired status and permitted revocation.

Your setup Confirm the shareable customer URL and QR presentation for your deployment. Creating or sharing a link is not payment. Automated email, SMS or WhatsApp delivery is not established by a link record.

• Create numbered invoices with customer details, line items, due dates and supported tax or discount amounts.
• Review issued, pending, paid, refunded or cancelled records, including recorded paid and outstanding amounts.
• Connect payment references and supported receipt/statement generation or report exports to the billing history.

Your setup A payment record does not independently confirm bank receipt. Branded invoice PDFs, receipt templates and partial-payment presentation depend on the enabled document workflow; automatic reminders need separate confirmation.

• Manage recurring-plan records with intervals, amounts, trial periods and configured retry schedules.
• Maintain customer subscription records, saved payment references and start, end or next-billing dates.
• Review recorded attempts and failed or past-due states; pause or cancel subscriptions where permitted.

Your setup Recurring management is implemented, not just a reusable token. Automatic production charging, consent collection, renewals and notification delivery still require a validated billing/provider arrangement; no blind retry after an uncertain charge.

• Search your scoped transactions, apply available filters and inspect transaction details and lifecycle timelines.
• Request permitted refund actions and inspect recorded outcomes, including supported full or partial amounts.
• Keep pending, timeout, unknown and InDoubt outcomes visible and use authoritative inquiry or recovery before another financial action.

Your setup Refund authority depends on role, transaction state and provider support. Capture, void and inquiry access must be confirmed separately; a request is not immediate completion.

• Review permitted settlement periods, gross/net amounts, fees and recorded reserve deductions or releases.
• Follow scheduled, processed and confirmed states, payout references and approved destination records.
• Keep settlement positions, stored-value balances and confirmed bank receipts distinct.

Your setup Payout requests and supporting records depend on your role and operating model. Reserve release stays with the authorized workflow; no instant payout or guaranteed settlement date is implied.

• Access permitted reconciliation views and source references from the merchant workspace.
• Compare available payment, invoice, provider and settlement evidence, including matched/unmatched states and fee differences.
• Follow investigation references and request supported exports for the records you may access.

Your setup Merchant access to each comparison, export or resolution action needs confirmation. This is not permission to edit scheme files or post unrestricted financial adjustments.

• View assigned pricing profiles and applicable effective dates within the permitted merchant scope.
• Inspect available fee rules and breakdowns for transaction, refund or settlement events.
• Connect recorded charges to the relevant currency and payment activity.

Your setup Visibility is separate from changing contracted pricing. Platform/partner configuration and confidential wholesale costs require their own permissions; commercial terms remain authoritative.

• The case-management scope includes linked transactions, case status and response deadlines.
• Supporting documents and evidence submissions belong to a permission-controlled operating workflow.
• Recorded financial impact and case history can inform the merchant follow-up agreed with your partner.

Your setup Case management is implemented, but merchant case access and document-submission rights need confirmation. Network submissions, representment and decisions depend on the operating partner; no successful outcome is promised.

• Merchant overview sources can provide permitted risk context or explicitly restricted panels.
• Applicable limits and recorded risk outcomes belong to the configured payment-control workflow.
• Discuss review requests and the specific settings your authorized role may change with your operating partner.

Your setup Merchant alert visibility and change/request permissions need confirmation. Platform fraud rules, AML cases and restricted investigations are not unrestricted merchant tools.

• Use enabled payment, refund, fee, settlement, reconciliation, dispute and store-related report definitions within your scope.
• Apply supported date, timezone and currency filters; check source freshness and distinguish an unavailable source from zero activity.
• Request supported CSV, Excel or PDF outputs according to the report definition and your export permissions.

Your setup Selected merchant report formats have identified internal test evidence, not universal report or production validation. Scheduling and live forecasting require separate confirmation.

• Maintain permitted merchant-owned customer profiles, notes and linked order records.
• Use Customer 360 to connect available invoices, payment/refund references and customer activity; wallet, rewards or BNPL panels require their own sources and permissions.
• Track supported order lines, amounts and lifecycle records without granting access to another merchant’s customers.

Your setup Missing correlations stay unavailable or link to the authoritative view. Communication history depends on connected sources. Order management is not a full inventory, shipping, tax or ERP service.

• Review currency-specific stored-value balances, holds, history and limits where your operating model enables them.
• Keep wallet ledger records separate from settlement positions and bank collection-account references.
• Use only permitted balance workflows; collection accounts and incoming-transfer controls need explicit provider confirmation.

Your setup Stored-value management is implemented. Source-IBAN allowlisting was not established for this offering and is not the same as an approved payout destination. Bank rejection/return behavior depends on the bank; MerchantPaisa does not independently issue bank accounts or accept deposits.

• Manage permitted merchant reward programs, earn/redemption rules, cashback configuration and reward catalogues.
• Review points, ledger history, voucher redemption and configured catalogue expiry, with points clearly separated from currency values.
• Record supported reward/cash split requests; these records do not establish a completed rewards-plus-card payment.

Your setup Program scope, full/partial redemption and refund reward-reversal policy must be agreed and validated. Platform-wide programs stay under platform permissions; financial confirmation comes from the relevant payment workflow.

• BNPL management records cover merchant enablement and customer application or eligibility states.
• Provider-decision records and installment schedules distinguish pending decisions from approval.
• Repayment and refund references support follow-up; merchant settlement and cancellation effects follow the contracted provider workflow.

Your setup Management implementation is evidenced; merchant self-service access is availability to confirm. Lending, credit approval, live installment collection and financing risk belong to the agreed provider/operating model, not automatic MerchantPaisa guarantees.

• Use merchant-scoped roles and supported store-level restrictions for business and payment operations.
• Review permitted users, access lifecycle and audit/activity history without parent-tenant or cross-merchant access.
• Authentication includes implemented MFA support; the newer delegated user-management flow includes constrained roles, account setup and session-revocation controls.

Your setup Delegated administration remains disabled by default pending deployment validation and approval policy. Sensitive actions require the applicable approval workflow; implementation does not mean it is enabled for every merchant.

• Obtain approved API documentation and an agreed sandbox environment during integration scoping.
• Use permitted merchant-scoped client/credential lifecycle controls; secrets stay outside this public website.
• Manage enabled webhook subscriptions and inspect recorded status or troubleshooting references within your developer permissions.

Your setup Credential issuance, endpoint access and webhook dispatch require deployment configuration. A queued/test delivery record is not confirmed delivery; no universal SDK, plugin or retry guarantee is implied.

• Merchant → partner/platform: use scoped tickets, comments, attachments and permitted transaction-linked enquiries.
• Customer → their own merchant: customer conversation access is a separate experience, not access to internal merchant support tickets.
• In-app notification records and preferences are distinct from email dispatch, native push, AI assistance and human handoff.

Your setup Ticket workflows are implemented. Email-provider delivery is not established by the notification records, and no response-time or 24/7 service promise is implied.

• Responsive web access is separate from a released native merchant app.
• Planned companion scope includes dashboards and payment, payment-link or QR visibility.
• Refund actions, settlements and notifications each need their own app-release and permission validation.

Your setup The native companion remains roadmap. There is no confirmed app-store release, live app screenshot or promise of action parity with the web portal.

• Configured customer payment journeys can connect to the relevant merchant’s checkout and invoice records.
• Planned customer-app scope includes the customer’s own receipts, refund visibility, rewards, BNPL and merchant communication.
• Wallets or accounts apply only under an enabled operating model; customer accounts never inherit merchant-management permissions.

Your setup The standalone customer application remains roadmap. Existing management records or hosted-session contracts do not establish a released customer app or every self-service action.

• The implemented foundation enforces merchant/store scope, evidence references and explicit unavailable or insufficient-evidence responses.
• Designed for private inference and private retrieval/embeddings where used: no OpenAI, Azure OpenAI, external AI processing or fallback.
• Controlled action proposals keep human approval and existing backend authorization in the workflow; no autonomous payment or routing changes.

Your setup The foundation is implemented; live private-model inference and credentialed merchant runtime validation remain unconfirmed and runtime is disabled by default. Broad transaction queries, forecasting and orchestration advice require separate evidence. The demonstration below is local sample content, not AI.

Explore the illustrative AI questions · Explore Private AI Copilot

• Operator-controlled tenant/partner branding supports approved identity, colors and workspace presentation.
• Enabled modules, report branding and contact presentation follow the agreed tenant configuration.
• Checkout/invoice appearance, custom domains and branded mobile applications each require their own verified implementation and commercial scope.

Your setup Brand configuration belongs to authorized operators. Merchant permissions do not imply control of the whole platform’s brand or ownership of a separately released app.