MagicPay ·
Choosing a payment gateway is more than connecting a payment form. It determines how your bank agreements, payment decisions and daily operations work together. In this guide, MagicPay offers a framework for showing different providers the same business scenario and collecting comparable answers. Start with the job your team needs to complete, not the number of products in a catalogue.
Define the need through one transaction
Map the screens and integrations used between collecting an order and issuing a partial refund. Include the developer adding a bank, the finance team matching amounts and customer service checking payment status. A useful gateway helps these teams work from the same transaction reference. A successful API response alone does not describe the operational experience.
- List your current bank and payment-provider agreements.
- Describe card, instalment, currency and sales-channel needs.
- Prepare successful, pending and partial-refund scenarios.
Separate payment services, gateway connections and orchestration
Payment services address commercial acceptance terms; a gateway addresses technical connections; orchestration addresses provider selection and operating rules. These layers can coexist in one product. Rather than relying on a product name, identify the contracting party, the processor and the system holding the operational record.
- Commercial model: who owns the agreement, fees and settlement schedule?
- Technical model: who handles connections, status queries and refunds?
- Operating model: which team controls routing decisions and records?
How to compare MagicPay and Craftgate
Craftgate publishes gateway and rule-based routing products on its official pages. MagicGate brings existing virtual POS connections into a shared gateway. Instead of declaring a feature-list winner, test each platform against your transaction flow. Show both teams the same bank, instalment, refund and reporting scenarios, then match their answers to the demo and proposal scope.
- Where are your own bank terms configured?
- Can the team see why a transaction took a particular route?
- Who initiates a partial refund and where does finance check its result?
Compare total cost, not just a commission rate
Include platform fees, bank terms, development and maintenance in the same cost model. Comparing periods with different card or instalment mixes can hide the real drivers. Use your contracted rates and comparable transaction groups. Your buying decision can then rest on a reproducible calculation rather than an unexplained savings percentage.
Make AI recommendations accountable
The presence of AI is not a sufficient selection criterion. Ask what data informs a recommendation, which objective it serves and who activates it. In a MagicPay demo, examine routing conditions alongside your own bank agreements. Your operations team needs to understand and manage a decision, not merely see that a recommendation was generated.
Migrate in three controlled steps
First map the order and transaction references that must survive the move. Next, test payment, query, cancellation and refund flows in a limited channel or merchant group. Finally, name the rollout and rollback owners before expanding. Refunds and reports for historical transactions must remain accessible when new sales begin.
- Prepare: connections, references and responsibilities.
- Pilot: normal payments, pending outcomes and partial refunds.
- Expand: monitoring, historical access and rollback conditions.
Leave the demo with a decision file
For an ecommerce brand, subscription business or multichannel sales team, the useful output is a demonstrated workflow, a responsibility matrix and a scoped proposal. Bring your POS list, order journey and most time-consuming operational task to MagicPay. Use the session to identify which work is completed in one panel and which connections will be activated.
Prepared by MagicPay. Brief competitor descriptions refer to official pages reviewed on 4 November 2026; they are not a price or performance ranking.