Integration is usually planned as a developer task and turns out to be a
project with three owners. The developer connects the API and the finance person reconciles what lands on the account. Meanwhile, somebody has to answer buyers whose payment behaved oddly. Teams that treat it as a one-week ticket discover the other
two roles in week three.
The work itself is not hard. What makes it drag is the order. A few decisions have to be made before the first line of code. Besides, redoing them afterwards is expensive.
Decide these four things first
Where the card data is entered. A hosted page run by the provider keeps card data out of your systems entirely. As a result, your compliance burden drops to the minimum. A form embedded in your checkout looks better and converts slightly higher. However, card data now touches your page and the compliance questions change. Most shops should start hosted and move later if conversion data justifies
it.
What happens after payment. The customer returns to your site,
but the authoritative signal is the server-to-server notification, not the
redirect. Build the order state on that notification. Shops that mark orders paid
when the browser comes back ship goods for payments that never settled.
Whether you charge immediately or reserve first. Selling
physical goods usually means authorise now, capture when you ship. Digital goods
capture straight away. Getting this wrong produces angry customers whose money was taken for an out-of-stock item. Alternatively, it produces expired authorisations and lost sales.
How refunds work. Someone will need to refund an order on day
two. Decide whether that happens in your admin panel or the provider’s dashboard. Decide too who has the right to do it.
The sequence that works
Start the account application before the development work. It takes from 5 days and runs in parallel with coding. The steps are laid out on
how it works.
While the paperwork moves, the capabilities you are integrating against are
described under processing.
What the acquirer actually reviews is set out on the merchant account page. Reading it before the kick-off saves a round of questions later.
While that runs, build against the test environment. A sandbox gives you card numbers that produce specific outcomes: approved, declined, timeout. Moreover, every one of those paths needs a handler. The
timeout case is the one teams skip and the one that causes duplicate charges in
production.
Then test with small real amounts before launch. Sandboxes behave politely;
real issuers do not. One live transaction per payment method, plus one refund,
catches most of what the sandbox hides.
Where integrations go wrong
Duplicate charges on retry. The customer taps «pay» twice, or
the network drops and the app retries. Without an idempotency key on the request,
both attempts become transactions, and you find out from the buyer. This is the
single most common defect we see.
Order state that drifts from payment state. Payment succeeds,
the notification is lost, the order stays unpaid. Build a reconciliation job that
compares the two daily rather than trusting every message to arrive.
Currency decided in the wrong place. The shop may show euros while the request goes in another currency. Then the customer sees an amount they did not agree to. Fix the currency at the point of display and pass it explicitly.
Authentication treated as an error. Strong customer
authentication is a normal step, not a failure. A checkout that shows «payment
error» when the bank asks for confirmation loses the sale at the last
centimetre.
What to agree with support before launch
Whoever answers customers needs three things on day one. First, a way to look up a payment by order number. Second, the authority to issue a refund without escalating. Third, a plain-language explanation of the failures that will actually occur.
Most tickets are «my card was charged twice» or «I paid but the order says unpaid». Therefore prepared answers to those two cover the bulk of the first month.
What to hand to the finance side
Integration is finished when money can be traced end to end, not when the test
payment goes through. Finance needs the payout report to match the orders. That means each settlement has to be linkable to the transactions inside it. Ask your provider what the report contains before you build the import. After all, rebuilding reconciliation later is slower than building it once.
If revenue lands in several currencies, decide early where it collects. A business IBAN in your own name keeps the chain simple. Settlement and outgoing payments stay in one place.
The commercial terms sit on the pricing page. There rates for middle-risk retail start from 1.8%.
A realistic timeline
For a standard shop on a common platform, the technical part is a few days of work. Add a week of testing. The account review runs from 5 days in parallel. The schedule slips when documents arrive incomplete or when the site contradicts the application. Prices differ from the checkout, terms are missing, contacts go nowhere.
Plan the launch after a quiet week rather than before a sales peak. The first
days after going live are when the edge cases surface, and you want attention
available when they do. We described the account side of this in the piece on
opening
a merchant account.
Connection from 5 days. Fees from 1.8% — transparent terms, no hidden charges.
Leave a request or book a consultation. We will put together the right setup for your niche and risk profile.