Paratika describes different payment-page and 3D authentication models. Review the current cart, customer return and post-sale requirements when planning the MagicPay connection, with a clear definition of when the order becomes paid.
Match authentication to the completed sale
Paratika distinguishes authentication-only from flows combining authentication with a sale. Successful bank authentication and collection can therefore be separate stages. Retain the payment-session and sale references together so that customer support can inspect the correct order after a return or interruption.
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 3D authentication and Direct Post flows are documented. Official source | Not yet confirmed |
| Installments | Subject to merchant terms Installments depend on eligible card programs and account scope. Official source | Not yet confirmed |
| Refund | In provider documentation The provider describes cancellation and refunds against the payment record. Official source | Not yet confirmed |
| Partial refund | Confirm the scope with us Confirm partial-refund amounts and transaction conditions separately. | Not yet confirmed |
| Card storage | In provider documentation Card registration and token-based payment examples are provided. Official source | Not yet confirmed |
| Currency | Confirm the scope with us Verify accepted currencies for the account and product. | Not yet confirmed |
| Preauthorization | In provider documentation The API documents a preauthorization option in the 3D flow. Official source | Not yet confirmed |
Plan your MagicPay connection in three steps
Review the Paratika 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 Paratika records. Keep order references, completed payments, pending authorizations where applicable and confirmed refund results distinct.
Frequently asked questions
Does completed 3D authentication always mean the sale is collected?
No. The selected model may separate authentication from the sale. Track both the payment session and final sale result before completing the order.
Can the review start with an existing Paratika 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.