MagicPay ·
Choosing Payment OS is different from accepting payments for a single merchant. The institution's merchant network, channels, financial records and permissions need to work together. MagicPay Payment OS is operational infrastructure for licensed payment institutions in Türkiye. This guide helps your buying team define demonstrations and acceptance around the institution's real working day.
Define the institution's role and operating boundary
Document the services you provide within your authorisation, the banks and partners you work with, and the teams responsible to merchants. MagicPay Payment OS is positioned as infrastructure for authorised payment institutions in Türkiye, not a direct store or consumer product. Technology selection should remain distinct from the institution's operating authorisation.
Build scope from workflows, not platform labels
Dgpays publicly describes platform areas including acquiring, issuing and wallets. Distinguish such broad categories from the particular workflows your institution needs. MagicPay Payment OS focuses on the shared operation of the merchant network, POS/gateway, ledger, approvals and reconciliation. Do not assume similarly named modules have identical scope: document their inputs, outputs and owners.
- Merchant operations: application, documents, products and activation.
- Payment operations: terminals, gateway, status queries and refunds.
- Finance operations: commissions, deductions, payables and reconciliation.
Follow one merchant from application to reconciliation
In a Payment OS demo, open the merchant record, representative relationship, products and terminal settings for the same example. Then review payments, refunds, commissions and net payables with their linked entries. Show the permissions and approvals of operations, finance and risk teams separately. This gives you an institutional workflow rather than disconnected module presentations.
Choose operating responsibilities with SaaS or on-premises
MagicPay Payment OS can be delivered as SaaS or on-premises. Go beyond the server location: define ownership of releases, access, backups, monitoring and incident management. Installing in your data centre does not remove operating tasks; SaaS does not remove institutional governance. The proposal should set out responsibilities and acceptance conditions for your chosen model.
- Deployment: environments, access and network boundaries.
- Operation: releases, monitoring, backups and rollback.
- Control: record access, change approvals and accountable owners.
Prepare institutional acceptance in three steps
Model merchants, representatives and terminals with a sample portfolio. Next test payments and financial entries using common references. Finally complete permissions, multi-approver workflows, failure handling and period-end review with the institution's teams. Base the go-live decision on their acceptance of these workflows, not merely delivery of a module list.
- Model the network and commercial conditions.
- Run payments, refunds, commissions and payable records.
- Accept permissions, approvals, reconciliation and rollback scenarios.
Build the evidence file throughout the demo
Keep the permission matrix, sample transaction chain, failure-test outcome and deployment responsibilities. If load testing is required, define the environment, traffic profile and success criteria first. For a security or compliance document, check the named entity, system scope and validity period. A supplier's general statement is not acceptance evidence for your own project.
Work through your institution's target journey
This guide is for product, operations, finance and technology teams at licensed payment institutions in Türkiye. Bring your service network, existing bank/provider connections and deployment preference to MagicPay. Select a representative journey from merchant application to review of financial records, then turn it into a concrete demo scope.
Türkiye's payment-services authorisation framework is based on Law No. 6493 and related rules. Procuring software does not confer authorisation or compliance approval; the institution's own scope and obligations still apply.