Payment Gateways in Türkiye: From Card Approval to Merchant Settlement

المسافر · Dec 8, 2025

Payment Gateways in Türkiye: From Card Approval to Merchant Settlement
Track authorization, capture, refunds and the transfer to your bank

“Payment complete” on a customer's screen begins a financial process; it does not prove the order value has reached the store's bank account. Owners need to know who approved the card, where the transaction was recorded, which event permits fulfillment and when funds can pay suppliers. This guide explains a transaction's journey in a store selling from Türkiye, with a practical record separating orders, payments and bank transfers. Every later figure is a hypothetical training example, beyond provider fees or announced settlement periods. The goal is to read your contract and reports and ask the right question when balances differ.

The payment journey starts with a clear order, amount and currency.

⁦⁩ Parties involved in the transaction

Customers use bank-issued cards; stores work with an acquiring bank or payment-service provider according to the service model. Card networks carry messages between participants, while the store platform records orders, products and addresses. A gateway may provide card entry, authentication and result delivery. Multiple parties explain why store messages may differ from phone notifications or temporary banking-app entries.

Map your contracted process: Who contracts with you, receives funds, transfers them to your account and responds to disputes? The plugin name may differ from the contract's legal entity. Keep separate financial and technical support details, along with internal-order and provider references. This prevents settlement problems reaching theme support or notification problems going to accounting.

Party	Practical role	What to verify
Store	Create and fulfill orders	Amount, address and stock
Issuing bank	Card decision and authentication	Result and decline code through the provider
Payment provider	Record transactions and report results	Transaction reference, contract and report
Merchant bank account	Receive payouts	Amount, date and payout reference

⁦⁩ Create a traceable order

Create a unique order number before sending a payment attempt and save the final amount after discounts and delivery charges, plus currency. Give each attempt its own number because customers may retry after a decline or interruption. If two successful attempts share an order number, detect them without creating two shipments. Names alone cannot reconcile payments: names repeat, and one person may pay for another's order.

Cart changes during the checkout return require a clear rule. Save the amount actually sent and compare it with the provider's confirmed amount. If pricing expires or stock changes, do not silently alter the old financial transaction. Open a defined customer-resolution process. Record order creation, attempts and provider results in a known time zone so a midnight difference does not look like a missing transaction.

⁦⁩ Card authorization and charging

Approval means the attempt passed the decision required by the payment flow, but holds, debits and capture depend on the service. Some solutions offer authorization followed by separate capture; others execute payment in a step directly linked to the order. Ask whether your service uses direct sales or preauthorization and how to interpret statuses. An amount in the customer's banking app is not final collection until the official status is checked.

For preauthorization, define who captures and when, and what happens if stock runs out or authorization expires. For direct sales, verify success, amount and currency before releasing orders. Fulfillment staff must distinguish an ongoing attempt from captured funds and have a list of shippable statuses. Build this internal procedure from your service documentation rather than one rule for every gateway.

Notice: A customer's charge notification or screenshot does not replace provider verification by the store.

⁦⁩ The role of 3D Secure authentication

3D Secure adds a card-use authentication step and may require customer action through the bank. Successful authentication does not automatically establish every later step's success; return flow, processing or result storage may fail. Keep status details the provider permits and never request verification codes or full card details through support.

Dispute liability depends on the reason, network and bank rules, contract and authentication outcome. Do not promise that 3D Secure eliminates fraud or chargebacks. Non-delivery and product-mismatch disputes still need evidence. Treat authentication, payment success and fulfillment as separate events linked by a reference, enabling accurate explanations without turning technical protection into a comprehensive financial guarantee.

Linking orders and transactions reduces fulfillment and refund errors.

⁦⁩ The authoritative result and order status

A customer-facing success page helps the buying experience but may open before server notification, or even be called without successful payment in a weak integration. PayTR documentation separates the customer return page from the result-notification endpoint and specifies notification handling. Solutions such as iyzico also provide transaction inquiries. Use an automatically verified trusted result, then update orders under store rules.

Map provider statuses to platform statuses. Awaiting payment does not mean Declined, and Paid does not mean Payout received. Pause fulfillment and query the transaction reference when statuses conflict. Assign someone to unresolved orders, with review times and documented decisions. Failed order storage after successful payment requires integration repair and transaction linkage rather than another payment request without checking.

Event	Suggested operational status	Decision
Attempt started	Awaiting result	Temporary stock reservation
Confirmed success and matching amount	Paid, ready for preparation	Fulfill after store checks
Conflicting result	Under verification	Query and pause preparation
Confirmed refund	Fully or partially refunded	Update balance and order

⁦⁩ From successful payment to settlement

Settlement combines financial movements under contractual schedules and conditions, producing an amount owed or paid to the merchant. Business days or other periods may separate sale and payout, affected by holidays, batch cutoffs, methods and risk. Read your service's timing, starting event and first-payout conditions. Do not forecast liquidity from another store's experience or an advertisement unrelated to your business.

Settlement reports may combine dozens of orders into one bank transfer. Retain payout references and included transaction details. iyzico settlement-file documentation includes transaction, commission, settlement-date and reference fields. Request exportable reports and retain every period. For delayed funds, first ask whether they are due, then whether sent, then whether received by the bank.

⁦⁩ Commission, reserves and refunds

Permanent deductions differ from funds held for later release. Contractual commission is a service expense; reserves or holds may relate to risk, returns or review. Do not record all held funds as losses or available cash. Request each deduction's basis, expected release date and conditions permitting reserve changes or payout delays.

Refunds may be deducted from unpaid balances or later payouts under the service's process. Ask whether commission is returned on cancellation or refund, whether separate fees apply and how insufficient balances work. Bank posting may take time, so retain refund references and results. Distinguish refund-request acceptance, financial completion and appearance in the customer's account.

⁦⁩ A hypothetical funds-flow example

Suppose a store records ten thousand lira in successful payments in one period. For calculation only, assume three hundred in commission, a five-hundred refund and a temporary one-thousand hold. Without other movements, the transfer is eight thousand two hundred lira. These are not iyzico or PayTR offers and exclude some taxes and contractual fees; they illustrate the difference between sales and payouts.

If the reserve is later released without further deductions, one thousand lira enters another batch. Do not count it as new sales. A refund for a previous sale appears in the appropriate financial period with its reference. Explain small payouts by breaking down components rather than assuming the bank took the difference. Use consistent positive and negative signs and document manual adjustments so calculations can be repeated.

Hypothetical item	Effect in lira	Explanation
Successful payments	10,000	Gross movement
Assumed commission	−300	Service expense
Confirmed refund	−500	Returned funds
Temporary hold	−1,000	Balance unavailable now
Expected transfer	8,200	10,000 − 300 − 500 − 1,000

Result: The payout is 8,200 lira; the 1,000-lira hold is a separate item requiring follow-up.

Settlement reports and bank statements clarify actually available funds.

⁦⁩ Reconcile orders, transactions and payouts

Keep at least three references: order number, provider payment identifier and payout or settlement reference. Link refunds to original payment identifiers, beyond refund dates. At period-end, start with successful transactions, match orders, settlement items and finally bank statements. Keep discrepancies with amounts, owners, possible reasons and resolution dates.

Address timing differences first, then amount, currency and unlinked transactions. A transaction may occur one day and enter another day's batch. Reports may include original amounts and lira-settled amounts; do not mix them or use unsupported manual exchange rates. Give accountants original files and item descriptions to distinguish sales, tax, commission and reserves under appropriate documents.

Record field	Hypothetical example	Why retain it
Order number	TR-2501	Link product and customer
Payment reference	PAY-EX-01	Status inquiry and refund
Settlement reference	SET-EX-07	Link the combined payout
Difference and owner	50 lira / finance	Prevent unexplained discrepancies persisting

⁦⁩ Provider licensing and what it does not determine

TCMB publishes institutions and authorized scopes, with revocation, termination and restriction details in its lists. Verify the contract's legal name, current status and required service scope when contracting. A brand alone is insufficient. Listing as licensed does not mean every activity, card, currency or store is accepted, or remove merchant-application conditions.

For banks or other solutions, understand the party's category and service rather than assuming all gateways are one institution type. Retain contracts, offers and approved contacts. Request written explanations of business acceptance, settlement schedules and reserves. If the contracting entity, bank-account request or contact channel changes, verify through a known channel before changing payout details or sharing sensitive documents.

⁦⁩ Test the full journey before launch

Test success, decline, leaving authentication, interrupted return flow, delayed notifications and repetition. Monitor order, inventory, customer-message and financial outcomes in each scenario. Sandbox testing verifies integration, beyond actual payout timing or business acceptance. After activation, perform limited authorized tests under provider instructions, checking reports, refunds and settlement.

Repeated notifications must be safe: receiving a result again must not create another invoice or shipment. Monitor plugin and platform updates; payments may work while result storage fails. Record the latest successful test and plugin version, with alerts for transactions lacking orders. Clear inquiry procedures reduce pressure to change statuses manually under customer demands.

⁦⁩ FAQs and readiness checklist

Good payment operations let support explain order status and finance explain payout differences without sharing card details. Give refunds separate permissions, an approval threshold and records of who acted and why. Retain operational evidence as necessary under data-protection policies, restricting access to those actually handling the transaction.

Review unresolved orders, overdue reserves and unmatched settlements weekly. Few complaints do not prove financial accuracy; recurring small differences may escape customers' notice. For larger differences, compare a short detailed period before tackling a month. Organized support files with references, dates, amounts and expected outcomes help locate causes faster.

Does successful payment mean money is available at the bank?
No. Check settlement dates and batch items, then receipt in the bank statement; payment and transfer are different events.

Should I request payment again if order status does not update?
First query the provider using order or transaction references. If successful, repair order linkage; if failed, follow a clear new-attempt process.

Does 3D Secure prevent every dispute?
No. Its effect depends on rules, dispute reason and authentication flow; delivery, product and communication evidence remain necessary for relevant disputes.

I linked each order, attempt and payout with saved references.
I documented payment statuses allowing preparation.
I read settlement, reserve and commission terms for my service.
I tested repetition, interruption and refunds without duplicate orders.
I prepared a discrepancy log, follow-up owner and bank statement.