Payment Integration Planning: Questions to Ask Before Development

Before choosing a payment provider, settle six questions: which methods your customers actually use, the total cost including currency conversion and chargebacks, when money reaches your account, how refunds and disputes are handled, what happens to stored cards if you switch provider, and who is liable when a payment succeeds but your order fails.

The last one is the question buyers skip and operations teams inherit. Payment integration is mostly the design of what happens when things go wrong.

Key takeaways

• Local methods decide conversion: In Turkey, instalment support is frequently the deciding factor rather than a nice-to-have.
• Compare total cost, not headline rate: Currency conversion, chargeback fees and settlement delay often exceed the percentage difference.
• Design the failure states first: Payment taken with no order created is the expensive case, and it will happen.
• Card portability is a lock-in question: Ask before integrating, not when you want to leave.

Start with how your customers pay

Payment method preference varies sharply by market and is not a matter of taste. Cards dominate in some markets, bank transfer in others, wallets in others again, and instalments matter enormously in some retail sectors.

For a Turkish customer base, instalment support and the specific bank relationships behind it commonly determine whether a basket converts. A cheaper provider without them is not cheaper.

Check what your existing customers already use where you can see it, rather than assuming. Adding rarely used methods costs integration effort and complicates reconciliation for every transaction afterwards.

Compare the total cost of accepting money

The advertised percentage is one component. A complete comparison includes the transaction percentage and fixed fee per method, currency conversion margin, chargeback and dispute fees, refund handling cost, monthly platform fees, settlement delay and its cash flow effect, and the cost of the integration itself.

Settlement timing is regularly underweighted. A provider settling in two days versus seven changes your working capital position materially, and for a business with thin margins that difference can outweigh a fraction of a percentage point on the rate.

Design the failure states before you build

Successful payments are simple. The cases that need real design are the ones in between:

• Payment authorized but your order service is briefly unavailable
• Customer charged twice through a retry or a double submission
• Payment succeeds after the customer has closed the browser
• Refund requested for a partially fulfilled order
• Stock disappears between authorization and capture

Each needs a defined behaviour, a named owner and a recovery path. The most damaging is money taken with no order recorded, because the customer knows immediately and your system does not. Ask any prospective provider how their webhooks and reconciliation reporting help you detect that within minutes rather than at month end.

Plan reconciliation from the start

Someone has to confirm daily that what the provider says it collected matches what your system says it sold. Without a designed process this becomes a manual spreadsheet task that grows with volume.

Establish which system is authoritative for order value, how refunds and partial refunds are represented on both sides, how currency conversion is recorded, and who investigates a mismatch. Ask the provider what reporting they offer for this specifically, and whether it can be pulled automatically.

For how this connects to the wider commerce build, see the e-commerce app development guide.

Understand your compliance position

If card data never touches your servers — because you use a hosted payment page, a redirect, or provider-hosted fields — your compliance obligations are substantially lighter. Handling raw card data yourself triggers far stricter requirements and is rarely worth it for anyone who is not a payments business.

Confirm which model each provider offers, and be careful with integrations that appear to keep the customer on your site while actually collecting card details through your own code. That distinction determines your obligations and is not always obvious from the sales material.

Ask what leaving looks like

Stored cards are the practical lock-in. If customers have saved payment details with your provider and you switch, those tokens usually do not transfer without a migration process the provider must agree to support.

Ask before integrating whether card tokens can be migrated to another provider, under what conditions, and at what cost. Providers that support it will say so. Providers that do not will answer vaguely, which is itself the answer, and it is far better to hear it now than in two years.

Related guides

Related reading:

• E-Commerce App Development: A Practical Planning Guide
• B2B E-Commerce Portal Development: Workflows Beyond the Cart
• Customer Portal Development: Workflows, Integrations, and Adoption

If the work prompted by Payment Integration Planning: Questions to Ask Before Development leads to a funded initiative that needs product strategy, design, engineering, or integration support, Discuss Your Commerce Platform.