iyzico's refund model identifies payment items separately. For an existing provider account, review how cart lines map to payment identifiers so that returning part of a basket can be traced to the correct collection.
Link payment-item identifiers to refund records
The refund documentation describes full or partial amounts using the payment-item identifier. Match the item line to that identifier and track how much has been refunded. When more than one request occurs, retain the remaining refundable amount and the original order context.
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 iyzico API documents a 3DS payment process. Official source | Not yet confirmed |
| Installments | Subject to merchant terms Installment and BIN queries are available; choices depend on the card and account. Official source | Not yet confirmed |
| Refund | In provider documentation Refunds using a payment-item identifier are documented. Official source | Not yet confirmed |
| Partial refund | In provider documentation Partial refunds are described within the remaining refundable amount. Official source | Not yet confirmed |
| Card storage | In provider documentation Card registration, query and deletion services are listed. Official source | Not yet confirmed |
| Currency | Confirm the scope with us Clarify the account's collection currencies separately. | Not yet confirmed |
| Preauthorization | In provider documentation Preauthorization is described with partial or full capture. Official source | Not yet confirmed |
Plan your MagicPay connection in three steps
Review the iyzico 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 iyzico records. Keep order references, completed payments, pending authorizations where applicable and confirmed refund results distinct.
Frequently asked questions
Which identifier matters when only one cart item is returned?
Match the item to the payment-item identifier described in the refund documentation. Track the requested and completed refund amounts against the remaining refundable amount.
Can the review start with an existing iyzico 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.