Param documents card storage and preauthorization with stored cards. When reviewing an existing merchant account for MagicPay, separate repeat purchases from the preparation of payments before delivery. Each collection should retain its own sale reference.
Distinguish stored-card identifiers from payment references
A card identifier relates to the returning customer, while a payment reference relates to a particular order. In preauthorization flows, distinguish the reserved amount from completed collection. This lets delivery and finance teams discuss the same order stage without treating a stored card as proof of payment.
Payment capabilities and integration scope
This table distinguishes published provider capabilities from merchant-specific conditions. A feature offered by a provider is not automatically enabled on every MagicPay connection.
| Capability | Scope and conditions | In MagicPay |
|---|---|---|
| 3D Secure | In provider documentation The stored-card payment documentation includes a 3D option. Official source | Not yet confirmed |
| Installments | Subject to merchant terms The installment field is documented; available terms depend on the card and account. Official source | Not yet confirmed |
| Refund | In provider documentation The merchant-panel material describes refunds. Official source | Not yet confirmed |
| Partial refund | Confirm the scope with us Confirm partial refunds for the service and transaction scope. | Not yet confirmed |
| Card storage | In provider documentation Adding, listing and deleting cards and paying with stored cards are documented. Official source | Not yet confirmed |
| Currency | Confirm the scope with us Confirm collection and settlement currencies for the account. | Not yet confirmed |
| Preauthorization | In provider documentation Param documents a stored-card preauthorization service. Official source | Not yet confirmed |
Plan your MagicPay connection in three steps
Review the Param account
Identify the existing merchant agreement, sales channel, store configuration and enabled products. Confirm the required payment scenarios and the separate MagicPay connection scope before activation.
Test the approved configuration
Authorized technical staff should configure credentials through a secure server-side channel. Compare successful, rejected and interrupted payments, and test refund or stored-card scenarios only where their scope has been confirmed.
Reconcile orders and payment results
After acceptance, compare the enabled transaction flows with Param records. Keep order references, completed payments, pending authorizations where applicable and confirmed refund results distinct.
Frequently asked questions
When should stored-card payment be considered?
For returning-customer scenarios in which card details are not entered again. Confirm the relevant Param service and separately test the scope available through the MagicPay connection.
Can the review start with an existing Param account?
Yes. Start with the current merchant product and agreement. Account permissions, technical access and the independently confirmed MagicPay scope must be reviewed before deciding which flows can be activated.
Does provider documentation confirm that a feature is ready in MagicPay?
No. The provider notes describe its published scope and merchant conditions. The separate In MagicPay column remains Not yet confirmed until the technical connection scope is independently verified.