In short and in plain language
Your shop is connected to payment services. These connections change often. Old versions are switched off.
The tricky part is that the shop keeps running as normal at first. Only later do payment messages go missing.
The article shows what helps. You keep a list of all connections. You track when old versions end. You match orders and payments.
We take on this care for your shop.
An online shop ages slowly. Its integrations age fast. While the ordering process, layout and catalogue can stay stable for years, payment and shipping interfaces change every few months: API versions are deprecated, signature schemes are replaced, certificates expire, webhook payloads gain new fields and status values. The tricky part is the order in which the symptoms appear. The shop keeps running, the homepage responds, the cart works – but the payment confirmation stops arriving, an order stays stuck in an open state, a refund is booked twice. The time pressure is real: since 9 October 2025, payment service providers in the euro area must offer verification of the payee (Regulation (EU) 2024/886, Official Journal of the European Union), and instant credit transfers must reach the payee's account within 10 seconds (European Central Bank). Both change data flows a shop depends on. This article shows how an integration register, a deprecation radar, webhook hygiene and a daily reconciliation turn a chance discovery into a plannable maintenance task.
Key takeaways
- Payment integrations age faster than the shop itself: version deprecations, new signature schemes, expiring certificates and silent payload changes. When the callback stops arriving, the ordering path stays green, uptime monitoring reports nothing and the order sits unpaid.
- The integration register records, per integration, the endpoint and API version, shutdown and certificate deadlines, a shared team address as the contact channel, a named owner, plus the last test and the rollback route. Without that list a provider notice reaches nobody.
- A deprecation radar is built from calendar entries, not technology: once a month, review release notes and status pages of every registered provider and log the result even when nothing is pending. Each deprecation carries two dates, the shutdown and an earlier internal target.
- A robust webhook endpoint verifies signature and timestamp before processing, stores event IDs as idempotency protection against double bookings, acknowledges immediately and processes from a queue, with a dead-letter store and alerts on rising failure rates.
- A daily automated reconciliation of orders, payment status and accounting entries against a defined tolerance surfaces paid-but-unmatched orders, duplicate bookings and refunds without a status change, on the same day instead of at month-end close.
- Regulatory deadlines can be planned: since 9 October 2025 the euro area requires verification of payee and crediting within 10 seconds (Regulation (EU) 2024/886), and payment page scripts must be checked at least every 7 days (PCI Security Standards Council).
Why payment integrations age faster than the shop
A shop installation is a largely closed system: what worked yesterday still works tomorrow as long as nobody changes anything. An integration is the opposite. It has two ends, and only one of them is under your control. At the other end sits a payment provider, a shipping provider or an accounting system with its own release cycles, its own security requirements and its own regulatory deadlines. Each of those deadlines eventually becomes a date on which an old API version is switched off – whether or not the shop is ready for it.
Four ageing mechanisms show up regularly in practice. First, version deprecation: the provider marks an API version as outdated, keeps it running through a transition period and then retires it. Second, a change of signature scheme: webhooks move to a new signing method or a new key, and old signatures lose their validity. Third, expiring technical certificates: client certificates for mutual TLS authentication or signing certificates have their own lifetimes, which rarely align with the maintenance calendar. Fourth, the silent format change: a field becomes optional, a status value gains a new variant, an amount switches from a decimal figure to the smallest currency unit. The first three mechanisms end in a hard, visible error. The fourth ends in wrong data – which can be considerably more expensive.
A shop cannot report an error it does not know about
On top of that comes a regulatory layer many operators underestimate: payment pages are watched separately. Requirements 6.4.3 and 11.6.1 of the card payment standard call for an inventory of every script executed on the payment page plus a mechanism that detects unauthorised changes at least every seven days; both have been mandatory since 31 March 2025 (PCI Security Standards Council, PCI DSS 4.0.1). If you maintain integrations anyway, it makes sense to run this check on the same cadence – as described in detail in the article on script monitoring for payment pages.
The integration register: know what is connected
The first step is unspectacular, which is why it is often skipped: a complete list of all active integrations. In shops that have grown over time, this list is longer than expected. Alongside two to four payment methods there are shipping labels, parcel tracking, inventory management, accounting exports, tax determination, credit checks, marketplace connections and newsletter handovers, each on its own interface. Every one of them has a version, an authentication method and an expiry date – and every one of them can fail silently. A register is the precondition for a deprecation notice ever reaching a person.
Endpoint and API version
Which base URL, which version, which channel? Without that detail a provider notice cannot be mapped to your own shop – the most common reason announcements go unread.
Expiry and shutdown date
The official end date of the version in use plus an earlier internal target date for the rework. Only the remaining days turn a note into a task with urgency attached.
Keys and certificates
Type of access, certificate expiry dates, key rotation interval and the place where credentials are stored. It is not the secrets themselves that belong in the register, but their deadlines.
Channel for notices
Which address does the provider use to announce changes? A shared functional address with several recipients survives staff changes; a personal mailbox does not.
Named owner
Who decides on the rework, who tests, who approves? An entry without a named person tends to be postponed until the deadline has passed (project experience).
Last test and rollback
Date and result of the last run plus the documented way back. In an incident, these two fields decide whether a disruption lasts minutes or hours.
A register is not an end in itself. In an incident it answers three questions in minutes rather than hours: which integration is affected, which version is currently live, and who at the provider can be reached? Without those answers, every incident starts with a search. That is why we keep the register as part of ongoing shop maintenance and update it with every release, because an outdated register is worse than none at all – it creates false confidence.
Deprecation radar: find notices before the deadline
Providers do announce shutdowns. The problem is rarely the missing announcement but its delivery path: a developer email to an address that no longer exists, a paragraph in release notes nobody reads, a status post in a developer portal. If you only look once an error appears, the entire transition period has been given away. A deprecation radar reverses the order: reviewing provider notices becomes a fixed, scheduled maintenance task instead of a chance discovery.
- A fixed date instead of a chance find: once a month, release notes, changelogs and status pages of every provider in the register are reviewed and the result is logged – even when there is nothing to report. It is precisely the empty log that later proves the check happened.
- A distribution list instead of a single mailbox: provider notifications go to a functional address with several recipients. If one person leaves the project, the channel remains.
- Every announcement becomes a date: a vague reference to next quarter turns into a calendar entry with separate blocks for rework, testing and buffer.
- Two deadlines per deprecation: the date the provider retires the old version, and the earlier internal date by which the rework should be finished. The gap between them is the actual buffer.
- Visible time remaining: how many days are left until shutdown? A register without a countdown invites postponement, because the urgency stays invisible.
- Dependencies included: a new API version often requires a newer PHP or library version. The link to the PHP lifecycle belongs in the same plan, otherwise a small rework turns into a large upgrade at short notice.
The calendar entry is the actual measure
Webhook hygiene: signature, idempotency, retries
Webhooks are the most sensitive part of a payment integration because they reverse the direction: the shop does not ask, the provider notifies. That shifts responsibility. The shop has to supply an endpoint that stays reachable, maps every message unambiguously, recognises duplicate deliveries and reacts traceably when something fails. Six properties separate a resilient endpoint from one that loses revenue when it matters.
- Verify the signature before processing: every incoming message is checked against the provider's signing scheme before anything is booked. Without that check the endpoint is an open door for forged payment confirmations.
- A time window for signatures: a timestamp in the signature header limits how long a message stays valid and prevents a recorded event from being replayed later.
- Idempotency keys: every event identifier is stored. If the same identifier arrives a second time it is acknowledged but not booked again. This is the most effective protection against double bookings.
- Acknowledge fast, process slowly: the endpoint confirms receipt immediately and hands the actual processing to a queue. Long processing inside the request leads to timeouts – and timeouts lead to retries.
- Retries with increasing intervals: if processing fails, it is retried with growing delays instead of running in a tight loop and putting additional load on the target system.
- A dead-letter store with alerting: events that stay unprocessed after all attempts land complete in a dedicated store, including payload and failure reason – traceable, replayable and with a notification to the responsible person.
The failure rate is the real early warning
These rules hold regardless of the individual provider, because they follow from the nature of asynchronous delivery: messages can be delayed, repeated, overtaken or lost. An endpoint that assumes a fixed order is therefore fragile. A robust endpoint derives each state from the event itself and discards an older status change once a newer one has been processed. How strongly such dependencies shape day-to-day operations is shown in the article on third-party outages.
Reconcile instead of trust: the daily comparison
Even clean webhook processing does not replace reconciliation. Events can be lost because an endpoint was briefly unreachable during a deployment, because a retry window expired or because a protection rule filtered a message out. The most reliable way to notice is comparing three data sets: orders in the shop, payment status at the provider and entries in accounting. If the totals do not match, a case to clear appears – on the same day, not at month-end closing.
| Check | What is silently lost | How reconciliation reveals it |
|---|---|---|
| Paid but not matched | The payment succeeded at the provider, the order still shows as open | Order without a processed payment event despite an existing transaction |
| Matched but not booked | The order counts as paid, accounting does not know the transaction | Difference between payment total and booked total per day |
| Booked twice | A repeatedly delivered event was processed two times | Two entries with an identical event identifier |
| Refund without return path | The credit note was triggered, the shop status stays on paid | Refund event without a matching status change on the order |
| Amount or currency shifted | A format change moves amounts by a factor of 100 or mixes currencies | Totals compared per currency against a defined tolerance |
Reconciliation does not need heavy machinery. It needs a fixed time of day, three data sources, a defined tolerance and a recipient for the deviation list. What matters is that it runs when nobody thinks about it – automated, with a notification once the tolerance is exceeded. In ongoing support this is a report that is empty on most days and valuable for exactly that reason: the few days with entries are the ones where money would otherwise sit unnoticed.
A payment event nobody misses is lost revenue on a delay.
The regulatory outlook as a planning input
Integrations change not only because providers modernise their software, but because the legal framework requires it. For payments in the European area, three developments are currently relevant, and each has a direct effect on data quality, master data upkeep and the amount of checking a shop has to do.
The instant payments regulation obliges payment service providers to offer, before a transfer is authorised, a check matching the payee's name against the account identifier and to warn the payer about any discrepancy; the service is free of charge for users (Regulation (EU) 2024/886, Official Journal of the European Union). In the euro area this obligation has applied since 9 October 2025 (European Central Bank). The matching follows a shared European payments scheme that puts the answer into clearly separated categories: match, close match with a name hint, no match, and verification not possible (European Payments Council, Verification of Payee Scheme).
For a shop this is not purely a banking matter but a master data question. Wherever transfers are initiated from the shop or payee details are handed on – refunds, payouts to marketplace sellers, supplier payments, invoice details with a differing account holder – the accuracy of the stored names decides whether a payment goes through without a query. Abbreviated company names, trading names instead of account holders and outdated bank details now produce visible warnings instead of silent tolerance. The upkeep effort shifts from the bank into the merchant's own data.
| Deadline | Payment service providers affected | Requirement |
|---|---|---|
| 9 January 2025 | Euro area | Receiving instant credit transfers, charge equality and sanctions screening (Regulation (EU) 2024/886) |
| 9 October 2025 | Euro area | Sending instant credit transfers and verification of the payee (Regulation (EU) 2024/886) |
| 9 January 2027 | Member States outside the euro area | Receiving instant credit transfers and charge equality (Regulation (EU) 2024/886) |
| 9 April 2027 | Payment and e-money institutions in the euro area | Receiving and sending instant credit transfers (Regulation (EU) 2024/886) |
| 9 July 2027 | Member States outside the euro area | Sending instant credit transfers and verification of the payee (Regulation (EU) 2024/886) |
In parallel, the pace is shifting. Instant credit transfers must be made available on the payee's account within 10 seconds (European Central Bank), and the former ceiling of 100,000 euros per instant credit transfer is being removed (European Central Bank). For a shop that means incoming payments arrive faster and in larger amounts than many downstream processes are used to. Anyone who ties approvals, shipping triggers and accounting reconciliation to nightly batch runs gives away exactly the time the regulation has just freed up.
The next stage is foreseeable. The European Commission tabled proposals for a new payment services directive and a payment services regulation on 28 June 2023 (European Commission); on 27 November 2025 a political agreement between Parliament and Council was reached on them (European Commission). It is therefore established that authentication and interface requirements will move again – with transition periods that can be planned for, provided the register is maintained. Anyone who does not know today which API version is in use will experience that changeover as an emergency rather than a scheduled date.
For card payments, script integrity on the payment page remains a separate checkpoint: every script executed there needs authorisation, an integrity measure and a documented justification, and unauthorised changes to scripts and to security-relevant HTTP headers must be detected at least every seven days (PCI Security Standards Council, PCI DSS 4.0.1). That check concerns the same pages as the payment integration and therefore belongs in the same maintenance cadence – as does the upkeep of consent scripts running on exactly those pages.
Regulation is a schedule, not an event
Test path: sandbox, test order, rollback
Every change to a payment or shipping integration needs the same procedure, no matter how small it looks. A provider update is not something you watch, it is something you verify. Six steps have proven themselves for that.
- Sandbox first: the new version is run against the provider's test environment, covering all event types – authorisation, capture, partial capture, cancellation, refund and failure. It is precisely the rarer cases that break later in production.
- A real test order after every provider update: a complete run in the live system with a small amount, clearly marked and refunded afterwards. Only that verifies the real data path all the way into accounting.
- Webhook replay: stored sample events are replayed against the new endpoint to demonstrate signature verification, idempotency and status logic – including a deliberately corrupted signature as a counter-check.
- A dry run on a staging environment: integration changes are checked there with production-like data before they touch the live system.
- A rollback plan: before the rework starts it is clear how the previous state is restored, how long that takes and who decides. Without that plan every mishap turns into a negotiation under time pressure.
- Maintenance windows with an eye on revenue: changeovers happen outside peak hours – which windows are suitable is covered in the article on maintenance windows without revenue loss.
The second point is the one most often missing. A sandbox reproduces the provider, but not your own environment: firewall rules, outbound IP addresses, certificate chains, timeouts in the upstream proxy. Only a real test order closes that gap. How the complete purchase path can be monitored continuously is described in the article on checkout and transaction monitoring. The distinction matters: monitoring detects the outage, maintained integrations prevent it. Together they produce a dependable payment path; neither replaces the other.
Documentation as handover value
Integration knowledge is the most volatile knowledge in shop operations. It is created during setup, then lives in a single head and disappears when the person or the service provider changes. That is why documentation here is not a by-product but the actual handover value – and the reason a change of operator proceeds in an orderly fashion rather than archaeologically.
Connection details
Endpoints, versions, authentication type, certificate lifetimes and the place where credentials are stored – without writing the credentials themselves into the document.
Event catalogue
Which webhook events are processed, which are deliberately discarded, and which status change follows from them? The catalogue makes the shop's behaviour verifiable instead of requiring explanation.
Procedures
Rollback path, contacts at the provider, escalation levels and the last test carried out with date and result. That is the basis for every handover and every piece of evidence.
These three building blocks also explain why integration upkeep belongs in a maintenance contract rather than a project. A project ends at go-live; an integration only starts ageing there. The article on what a maintenance contract should include sets out which services are usually part of it and which are agreed separately.
Integration upkeep as part of the maintenance scope
In practice the task consists of four recurring appointments: the monthly review of provider notices, the ongoing evaluation of the webhook failure rate, the daily reconciliation and the test after every provider update. None of those is demanding on its own. It becomes demanding only when they are missing and a retired API version surfaces during live operation.
We run these points as a fixed part of our maintenance services: an integration register with versions and expiry dates, a deprecation calendar with lead time, alerting on rising webhook failure rates through technical monitoring, daily payment reconciliation with a deviation report, and documented tests after every provider update. If something still goes wrong, emergency support steps in with an agreed response time – and the rollback is prepared rather than improvised.
The commercial point is simple: a retired API version does not cost the rework time, it costs the time until discovery plus the clean-up of everything that was booked wrongly or not at all in the meantime. The ratio is unpleasant – the rework takes hours, the clean-up takes days. Knowing the dates trades clean-up for planning. That is the difference between a payment path that is looked after and one that is merely hosted.
Sources and studies
Related Articles
Downtime Cost 2026: What a Shop Outage Costs per Minute
What a shop outage costs per minute in 2026: direct and indirect costs, why detection under 2 minutes matters and how 24/7 monitoring protects revenue.
Checkout Monitoring: Catch Silent Order Failures
Synthetic transaction monitoring catches silent checkout failures: check cart, coupon, payment and OTP every minute from several regions before revenue drops.
Shop Server Logs: How Long IP Addresses May Be Stored
How long may IP addresses stay in server logs? What the GDPR requires, what the five weeks from the BfDI mean, and how rotation, truncation and backups fit in.