PTT presents Virtual POS alongside physical POS under PttPOS, while PTT Akilli Esnaf has separate application and collection options. Start the MagicPay scope review with the exact service in your existing payment-acceptance agreement.
Identify the sales channel for PttPOS and Akilli Esnaf
PTT describes website Virtual POS integration and payment-link collection as different journeys. Establish whether the customer completes a store checkout or follows a shared payment link. Match that route to the contracted product, the transaction-report source and the team responsible for refund requests.
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 | Confirm the scope with us Confirm 3DS for the selected PTT service. | Not yet confirmed |
| Installments | Confirm the scope with us Verify installments against the service and agreement. | Not yet confirmed |
| Refund | Confirm the scope with us Clarify the refund channel and connection scope. | Not yet confirmed |
| Partial refund | Confirm the scope with us Explicit technical confirmation is required for partial refunds. | Not yet confirmed |
| Card storage | Confirm the scope with us Stored-card use has no confirmed scope in the reviewed material. | Not yet confirmed |
| Currency | Subject to merchant terms The currency depends on the relevant service account. | Not yet confirmed |
| Preauthorization | Confirm the scope with us Investigate preauthorization for the specific service. | Not yet confirmed |
Plan your MagicPay connection in three steps
Review the PTT 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 PTT records. Keep order references, completed payments, pending authorizations where applicable and confirmed refund results distinct.
Frequently asked questions
Should PttPOS and payment-link collection be treated as the same product?
No. Use the service named in the agreement and identify where the customer starts payment. Keep the order reference, reporting source and refund contact aligned with that service.
Can the review start with an existing PTT 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.