Plan payments from sale to reconciliation
Suitable processing links sales to traceable money and information flows. Required methods, integration, terms, payouts and refunds matter. Compare the complete process.
Define the payment process
This service covers electronic customer payments online, at the point of sale or through a payment request. Specify a new setup, provider change, comparison of terms or improved reconciliation. Replacing a device and changing processing are distinct assignments.
Describe sales channels and known systems together. For multiple shops or sites, give their counts and differences without treating a sales channel as one till. Technical integration and commercial agreements need the same scope.
Separate technical connection and acceptance
The technical platform provides the payment flow and connections to payment methods. Acceptance and settlement of a method can need additional agreements. Even in a combined package, contract parties, service boundaries and fees should remain clear.
An available interface does not mean a method is activated. Check business requirements, permitted markets and currencies and the onboarding process. An initial quote does not replace contract checks or guarantee acceptance of your business.
| Area | Confirm |
|---|---|
| Payment platform | Supported systems and flows |
| Acceptance | Methods, contract parties and activation |
| Payout | Timing, currency and deductions |
| Reconciliation | References, reports and matching |
Choose integration for existing systems
A shop module, hosted payment page and custom interface need different setup and maintenance effort. Have known software and versions checked. An available extension helps only if it supports the required methods and flows.
Define which system handles the authoritative payment status and who manages errors. The customer returning to the shop must not be the sole basis for order handling. Agree tests for success, cancellation, delayed results and refunds.
Choose payment methods and markets deliberately
Choose for actual sales: cards, mobile methods, bank payments and invoice solutions have different flows and requirements. A long list of logos is not a suitable selection. Check recurring payments if the business model needs them.
Distinguish customer currency, charge currency and desired payout currency. Check conversion, particular card types and cross-border charges in the actual offer. Availability and fees are not identical across countries and methods.
Trace payouts and fees
A payout can combine multiple payments and deductions. Accounting needs a trace from order and payment through fees to payout. Clarify reports, references and required exports rather than looking only at the bank deposit.
Payout timing, initial release and possible reserves depend on contract and circumstances. Do not plan cash flow around an unconfirmed instant payout. For manual payouts, separately clarify who reconciles the underlying transactions.
Organise refunds and disputes
Cancellation before completion, refund after payment and a dispute are distinct operations. Check responsibilities, deadlines, status notifications and fees. A refund does not automatically return the original processing charges.
Test partial, failed and pending refunds where relevant to your methods. Clarify order handling and customer communication. Real payment data and receipts do not belong in the initial comparison enquiry.
Build a common cost comparison
Use the same monthly volume and payment-method mix for every offer. Sensible planning ranges can suffice initially; refine counts and amounts before signing. Distinguish setup, fixed charges, per-payment costs and percentage fees.
Include minimum charges, conversion, refunds, disputes, exports and switching effort. Compare the lowest-cost suitable complete service for required functions and timing. A low standard rate does not establish low total operating cost.
| Item | Comparison basis |
|---|---|
| Setup | Modules, custom work and tests |
| Fixed charges | Same term and included services |
| Transaction costs | Counts, amounts and method mix |
| Special operations | Refunds, disputes and conversion |
| Switching | Cancellation, data access and handover |
Launch with clear responsibilities
Start with scope and technical requirements, then binding terms and necessary contract checks. Agree setup, tests and acceptance with the responsible parties. When switching, pending payouts, refunds and historical reports must remain manageable.
Initially describe known systems, business flow and scale. Credentials, card numbers, bank-account records and customer dossiers are unnecessary for comparison. Agree any later secure data migration separately.
Frequently asked questions
Are payment platform and acceptance the same?
They are distinct functions that a package may combine. Still check each contract party and service boundary.
Must I disclose my bank account for a quote?
Scope, systems and planning ranges suffice initially. Later contract checks use an agreed secure process.
Is every payment method immediately available?
Technical support, agreement and activation must fit. Confirm availability for your business and market.
Does one payout equal one order?
Not necessarily. Payments and deductions can be combined; suitable reports support reconciliation.
Are all fees returned on a refund?
That depends on agreement and operation. Check original processing charges and possible extra refund fees separately.
Are planning ranges useful initially?
Yes, for initial matching. Compare final terms later using a more precise common count and amount basis.
Could switching affect access to old reports?
Before cancellation, clarify access, exports and pending operations. A new solution does not automatically take them over.
