Observability for a normal web service answers one question: is the system up and fast. Observability for money movement has to answer a harder one: is every dollar still accounted for. A request that returns 200 in 40 milliseconds can still have charged a customer twice, settled into the wrong account, or left a payment stuck between your ledger and the processor. Latency and error-rate dashboards will not catch any of that.
This module is about the signals, alarms, and incident habits specific to money. We assume you already have a correct ledger (module 4), idempotent writes and webhook handling (module 5), and a reconciliation job (module 6). The job here is to know, in near real time, when one of those is failing, and to respond without making the financial state worse.
Instrument the money, not just the service
Your standard golden signals still apply, but they are necessary, not sufficient. Stack three layers of signal.
Layer 1: request health
Track latency, error rate, and throughput per processor call and per webhook endpoint. Tag every metric with the route to the money: PSP name, payment method, currency, and whether the call hit a fallback path. When you orchestrate multiple PSPs (module 3), a single blended error rate hides the case where one processor is degraded and traffic should be shifted off it.
Layer 2: authorization and decline quality
The single most useful business signal in card payments is the authorization rate, with declines broken down by reason. Soft declines (issuer says "try again later") behave nothing like hard declines (issuer says "never"), and in subscription businesses soft declines are the large majority of all declines. Watch authorization rate sliced by issuer, BIN, region, card brand, and descriptor, because a drop usually shows up in one slice first. A site-wide auth rate that looks flat can mask a 20 point collapse for one issuer or one new BIN range.
Layer 3: financial integrity
This is the layer most teams skip. Emit metrics for the things that should always be true: count and value of payments in each lifecycle state, age of the oldest payment stuck in pending or processing, count of ledger entries that do not balance, and the size of the gap between your records and the processor's at each reconciliation run. These are the signals that catch silent money loss.
Pick alarms that map to money at risk
Alert on the financial-integrity layer, not just the request layer, and tie each alarm to a specific failure you can act on.
Useful money-movement alarms include: reconciliation break value above a threshold (not just break count, because one large break matters more than fifty cent-level rounding differences), webhook processing lag above a few minutes, any payment older than N hours still in a non-terminal state, idempotency-key collisions resolving to different request bodies, and authorization rate dropping more than a few points below its trailing baseline for any major issuer.
Two practical rules. First, alarm on rate of change and on absolute floor, because a slow leak and a sudden cliff are different incidents. Second, give every money alarm a runbook link in the alert payload itself, so the responder is not hunting for what RECON_BREAK_HIGH even means at 3am.
A worked example
Your auth rate dashboard shows a 3 point dip overall, easy to dismiss as noise. The per-issuer slice tells a sharper story: one large issuer fell from 91 percent to 68 percent at 14:05, and the decline-reason breakdown shows the new volume is all "do not honor" rather than insufficient funds. That pattern points away from your customers' balances and toward something you changed: a new descriptor, a misformatted AVS field, or a token migration that the issuer is now refusing.
You correlate 14:05 with a deploy that changed the statement descriptor. The dollars at risk are concrete: failed authorizations per minute multiplied by average order value, for the affected issuer only. That number, not "auth rate is down a bit," is what decides whether you roll back immediately. You revert the descriptor, watch the issuer slice recover within the retry window, and the overall dashboard catches up afterward. Without the issuer-level slice and the decline-reason tag, this reads as background noise for hours.
Run the incident without corrupting state
Money incidents have a constraint normal outages do not: the wrong remediation can lose real funds. A retry storm during a processor blip can double-charge customers. A hasty database fix can leave the ledger and the processor permanently out of sync.
Stabilize before you repair
When a money path is failing, your first move is often to stop new damage, not to fix the broken transactions. That can mean pausing a retry job, disabling a degraded PSP in the orchestration layer, or putting a circuit breaker in front of the failing call. Stop the bleeding, then reconcile.
Trust the ledger as the source of truth
During an incident, resist editing balances by hand. Your ledger (module 4) and your reconciliation output (module 6) are the record of what is true. Repair by replaying events or reprocessing the reconciliation, not by patching rows, so that the audit trail stays intact. Every manual money mutation is a future mystery break.
Keep an incident-grade audit trail
For money incidents you need to reconstruct exactly what happened, often months later and sometimes for a regulator or a card network. Make sure logs carry the idempotency key, the PSP reference, the internal payment ID, and the ledger entry IDs on every step, so any disputed transaction can be traced end to end. This same trail is what lets you answer a chargeback or a network inquiry with evidence rather than a guess.
Watch the thresholds that bite externally
Some incidents are slow-burn compliance failures, not outages. Visa's Acquirer Monitoring Program, which began enforcement on October 1, 2025, scores acquirers and merchants on a fraud-and-dispute ratio, and the merchant threshold tightens further in 2026. A rising dispute rate is an incident you want to detect from your own dashboards weeks before a scheme notice arrives, because by the time the notice lands you are already in remediation. Treat fraud and dispute ratios as monitored signals with their own alarms, not as quarterly reports.
Takeaway
For money movement, observability means proving the money is still right, which is a higher bar than proving the service is up. Instrument three layers: request health, authorization and decline quality, and financial integrity. Alarm on dollars at risk and on broken invariants, route every alert to a runbook, and during an incident contain the failure before you repair. When you do repair, work through the ledger and the reconciliation pipeline so the audit trail survives, because the question someone asks later is never "was it fast," it is "where did the money go."