Mobile Checkout in Türkiye: Carts, Payments and Abandoned Orders

سفير تركيا · Monday at 12:01 AM

Mobile shopping: locate the obstacle and test the fix
Carts, addresses, payments and abandoned-order recovery under clear rules

Purchase testing starts with the customer’s actual experience.

Mobile customers buy on small screens, with interrupted networks, keyboards covering buttons and trips to banking apps and back. Improving the journey requires locating drop-off, investigating its cause and testing a measurable change. This guide covers Turkish sellers of physical products through independent stores, combining Shopify and WooCommerce practices while recognizing configuration differences. Do not begin by reminding everyone who abandoned a cart. Establish whether they stopped before learning shipping costs, during address entry or after payment rejection, and whether actual collection needs reconciliation. Figures and calculations are educational examples, neither Turkish market benchmarks nor sales-growth promises.

Map the purchase journey with one definition per step

Define product view, cart addition, checkout start, payment attempt and confirmed paid order. Keep sessions, customers and orders clearly defined and use one measurement unit for stage transitions. Users at one stage and sessions at another produce an unreliable ratio. Exclude team tests and known automated activity where possible and review repeat visits before purchase.

The example uses linked shopping sessions in a hypothetical period, treating each later stage as a subset of the previous for modeling. The largest numerical loss is not necessarily the hardest problem; compare volume with tested causes. Lawfully retain limited device, language and traffic-source data to identify general obstacles or those linked to an Arabic interface, campaign or particular gateway.

Hypothetical stage	Count	Transition from previous stage
Product-view sessions	5,000	Starting point
Add to cart	600	12% of views
Checkout started	300	50% of carts
Payment attempted	180	60% of checkout starts
Confirmed paid order	150	Approximately 83.3% of attempts

In this model: 150 ÷ 5,000 = 3% overall conversion. Actual system definitions may differ; document them before comparing.

Test performance on realistic phones and networks

Measure content appearance, touch responsiveness and layout stability, then perform tasks on a representative phone. Current Core Web Vitals cover LCP for loading, INP for responsiveness and CLS for layout stability. Use metrics to locate fixes, then inspect the customer journey: a good score can coexist with confusing size menus or shipping messages. Do not generalize a powerful-device laboratory result to every user without suitable comparison.

Start with the main image, page file sizes and apps loading unnecessary prepurchase elements. Review loading that shifts buttons after a tap, advertisements obscuring cart summaries and videos delaying products. Test slower networks and open keyboards. Give developers the problem, page, conditions and required outcome, comparing before and after under identical settings.

Make product decisions clear before the cart

Show price, currency, available option, sizing and contents near the add button. Verify variant selection changes image, price or availability correctly and never silently adds an unnoticed default. Place size-chart links where decisions are made, avoiding long searches for differences determining what arrives.

If using a sticky button bar, check whether it obscures descriptions or options and shows the correct selection. Test one unavailable variant with others available. Returning from the cart should allow size changes without accidentally duplicating products. Repeated support questions belong at the decision point; monitor related questions and cancellations afterward while preserving useful technical detail for those needing it.

Reveal shipping and totals before surprises

Clearly show delivery cost or calculation method, service coverage and preparation time, then final amount before confirmation. If address determines shipping, explain early and provide estimates or calculators where available, followed by exact costs once data exists. Precontract information includes tax-inclusive prices and applicable extras. Do not preselect paid services requiring customer consent.

Review free-shipping thresholds, discounts and mixed baskets, including quantity changes and product removal. Explain total changes rather than using vague messages. Handle unserved addresses clearly instead of generic technical errors. If departures cluster when delivery appears, examine expectations, cost and tariff together: lower delivery fees need margin calculations, while wording changes need clarity testing.

Successful payment needs clear confirmation matching provider records.

Reduce address friction and improve errors

Collect data needed for delivery, invoicing and payment, then assess every field. Do not remove shipping-contract or accounting-required fields merely to reduce count; improve labels, order and selection. Explain province, district, neighborhood, building and apartment under your system and accept Turkish characters and Arabic names where required. Test long addresses, pasted text and city corrections after other details are entered.

Tie understandable errors to fields: invalid numbers, incomplete postcodes or unserved areas. Preserve entered text when another field fails and use appropriate keyboards where supported. Check browser autofill, which may misplace street names or mix billing and shipping addresses. Verify shipping-label output too; screen acceptance does not guarantee correct carrier data.

Review guest checkout and accounts without excessive friction

Where order type and settings permit, test guest checkout followed by optional account creation for tracking or future orders. WooCommerce offers guest and account settings, while subscriptions and other services may need accounts. A one-time physical-goods decision cannot govern every service. Review Shopify’s currently available account journey and test as a new customer.

For genuinely required accounts, explain why and make login and recovery clear. Test existing emails, expired login codes and undelivered messages. Registration prompts must not erase a ready basket. Review tracking privacy and order-status links, preventing personal-data access through generic URLs. Record the reason for required accounts and their completion impact.

Separate information and consent from marketing

Contract-performance data may have an appropriate basis other than explicit consent, while privacy notices and correct handling remain necessary. Review each field’s purpose and separate contract acceptance or service requests from marketing choices. KVKK Decision 2025/1072 specifically addresses combining purposes through one verification code and misleading implications that marketing is a service condition. Explain code functions before entry and provide independent choices.

Test a marketing refusal and verify lawful fulfillment continues and the choice is stored. Do not preselect marketing or bury it with the purchase in a long sentence. Review session, heatmap and recording tools, specifying collected data, masked sensitive fields and appropriate basis. Conversion optimization does not require sending customer details or payment fields to every analytics tool.

Diagnose payment failure before requesting another attempt

Distinguish known declines, technical faults, interrupted returns and provider-confirmed payments absent from orders. Reconcile using order number, transaction ID and attempt time. Never request full card photographs or verification codes. Explain the appropriate next step without exposing exploitable details and identify support able to access the case.

External-provider confirmations or return links may fail despite successful transactions. Check provider records before requesting payment or replacement orders. Test banking-app returns, authentication rejection, session expiry and repeated taps for duplicate orders or charges. Operations must distinguish manual status changes from verified collection and retain reconciliation decisions. Fixes must respect gateway protections and contract rules.

Early knowledge of delivery costs helps customers decide whether to order.

Choose one measurable hypothesis

Turn observations into hypotheses: shipping information near the cart may reduce checkout exits; clearer address errors may improve gateway progression; lighter visual elements may improve product responsiveness. Define the change, primary metric and guardrail against harmful apparent success, such as more cancellations or lower order margin. Fix basic errors first, then test design on a working journey.

Choose a suitable schedule or allocation without mixing new campaigns, major discounts or stockouts with interface effects. With few orders, use qualitative tests and operating outcomes without claiming statistical confidence. Exclude training and test data from production reports and define metrics before seeing results. Small documented decisions are easier to evaluate and reverse than redesigning every page simultaneously.

Observation	Specific change	Primary metric	Guardrail metric
Drop-off after shipping appears	Explain its calculation in the cart	Cart-to-checkout progression	Order margin
Recurring address error	Field label and help	Address completion	Incorrectly addressed shipments
Delayed button	Reduce a heavy loading element	Journey responsiveness and completion	Variant functionality
Account requirement interrupts purchase	Test guest checkout where appropriate	Confirmed orders	Fraud, support and reconciliation

⁦⁩ Test phones, returns and interruptions

Start in a test environment avoiding unintended live collection or documents, then agree an appropriate live-payment test with the provider. Use representative devices, browsers and networks and published Arabic and Turkish versions. Check keyboards, landscape view, scrolling, one-handed taps and help links opening new windows. Record page, steps, expected and actual results.

Maintain acceptance checks after updates. Themes, languages, gateways and shipping changes can reintroduce solved problems. Test guests, account holders, two addresses and variant baskets rather than relying on an administrator with saved data. Assign failed cases an owner and fix date, then repeat the same case before declaring success. One clear confirmation should arrive with matching order, amount and shipment data.

Case	Team check	Acceptance criterion
Small phone and open keyboard	Button, fields and errors	Nothing blocks progression
Arabic and Turkish	Option, address and total	Matching meaning and data
Banking return or interruption	Transaction and status	No duplicate collection or order
Cancellation or refund	Payment, stock and document	Correct record and understandable message

⁦⁩ Manage abandoned-order recovery within the rules

Abandoned carts and checkout exits are not necessarily identical, and email may be unknown in the first stage. Review platform definitions before automation. Shopify’s newer Messaging-based recovery differs from its older experience; check documentation and actual configuration. Sending options for wider audiences do not establish legal eligibility in Türkiye. A completion reminder may be marketing, so assess consent, IYS and content for the case.

Do not mix existing-order service with advertising or discounts for incomplete orders. Define an eligible audience, timing, limited contact count and clear opt-out, excluding completed orders, refusers and unavailable products. Send recovery links only to the order owner because they may expose the journey and data. The next hypothetical calculation neither establishes that messaging caused the full difference nor that every new order is profitable.

Hypothetical comparable period	Product sessions	Confirmed orders	Overall conversion
Before the change	5,000	150	3%
After the change	5,000	180	3.6%
Change	Same model volume	30 additional orders	0.6 percentage points; 20% relative increase

Recovered orders may complete without clicking a message; review attribution, discount cost and cancellations before calculating benefit.

⁦⁩ Answer questions and choose the next decision

Does every abandoned order mean the price was rejected?
No. Customers may browse, enter incorrect addresses, encounter payment failure or return later. Reconcile records and testing before choosing a cause.

Can I send a reminder because I have the customer’s email?
Possessing email does not determine message purpose or processing basis. Review reminder type, permission, IYS and opt-outs before sending, separately from existing-order notifications.

Does conversion rising from 3% to 3.6% mean only a 0.6% increase?
The difference is 0.6 percentage points and the relative increase 20%, because 0.6 ÷ 3 = 0.2. This example proves neither causation nor profit.

Journey stages and measurement units are defined.

Mobile, language, address and shipping are tested.

Marketing refusal does not block lawful orders.

Failed payments are reconciled before another attempt is requested.

Tests change a clear element and monitor side effects.

Recovery respects message eligibility and opt-outs.

Choose the highest-impact obstacle you can establish, make one fix and compare under similar conditions. Retain the learning and repeat testing after significant updates.