Integrations & Third Parties

Fernway doesn't process cards — Paylane does. It doesn't send email — a mail service does; doesn't draw maps — a maps provider does; doesn't handle "log in with Google" — Google does. Modern products are assembled from other people's services, and the seams where they join are one of the great natural habitats of bugs: places where two systems can each work perfectly and still disagree. You met this at the integration level in Chapter 3; this page makes it concrete, testable, and slightly frightening in the useful way.

The wedding is the right picture. Caterer, florist, band — each excellent alone. The failures that ruin the day live between them: the florist decorates the hall the caterer isn't setting. Rehearsals exist to test the seams, not the vendors — and so does this page.

Why Seams Breed Bugs

Three mechanisms, each a bug family. Mismatched assumptions: two systems agree on the words and disagree on the meaning — currencies, date formats, and time zones (FW-312's entire extended family lives on seams). The Mars Climate Orbiter was a seam failure at planetary price. Timing: the answer that arrives late, or twice, or never — Paylane confirms a payment with a callback message, and what if that message takes five minutes? Arrives after the traveler closed the tab? Arrives twice? Partial failure — the scariest: the payment succeeded and the confirmation email died. Is the booking confirmed? The traveler was charged and holds nothing that says so. Each mechanism produces bugs where both sides pass their own tests — only testing the seam finds the disagreement.

Testing What You Don't Control

Here's the tester's structural problem: you can't make Paylane fail on demand. It's someone else's service; its failures arrive on its schedule, not your test plan's. Two tools solve this. Sandboxes you know from Chapter 2 — the provider's own rehearsal instance, taking test cards, moving no money. Sandboxes are great for happy paths and provider-defined test scenarios (most payment sandboxes have magic card numbers that trigger declines — use them). But for full control, teams build test doubles: stand-ins that pretend to be Paylane and fail exactly when told to. Two vocabulary words, one line each: a stub returns canned answers ("whatever you ask, the payment succeeded"); a mock additionally checks it was called correctly. The trade-off, stated honestly: a double can drift from the real service's behavior — you're testing against your team's beliefs about Paylane, which is why doubles complement sandboxes rather than replace them.

The Cases Every Integration Owes You

For each seam, a standard family of tests — the integration workup, as reusable as Chapter 4's field workup. What happens when the third party is slow (does checkout hang forever, or time out gracefully)? Silent (no answer at all — the FW-356 arrow, remember, was exactly an unhandled payment-failure event)? Answers with an error (declined card: clear message, booking not created, no charge)? And — FW-360's lesson generalized — answers or gets called twice? The double-charge taught Fernway the word idempotent: an operation safe to repeat, because the second attempt recognizes the first. "Pay for booking FWB-20871" should be idempotent — a retry must find the existing payment, not create a sibling. New word, permanent catalog entry: every money-moving seam gets the duplicate test.

The Payment-Succeeds, Email-Dies Test

The partial-failure case, run for real. With a double standing in for the mail service — told to fail on command — you book a stay: Paylane's sandbox approves the charge, the email double refuses to send. Result: the booking quietly lands in confirmed, the traveler is charged... and nothing anywhere tells them so. No email, and — you check — no visible confirmation state in their account beyond a status word. A support ticket generator, mass-producing itself every time the mail provider hiccups. The team's fix isn't "make email never fail" (impossible — it's a third party); it's a designed degradation: the account page shows the full confirmation prominently, email becomes a nice-to-have copy, and a retry queue resends failed emails. The seam keeps its failure mode — but now it's a designed one. That's the realistic goal of integration testing: not seams that never fail, but seams that fail on purpose, visibly, recoverably.

Whose Bug Is a Third-Party Outage?

Last mindset piece. When Paylane goes down, Fernway didn't break — but a traveler mid-checkout doesn't care whose logo is on the failure. Their outage, your user experience: what the traveler sees during a provider failure is 100% Fernway's to design, build, and test. If the story doesn't say what checkout shows when payments are unreachable, that's a Chapter 2 ambiguity — file the question. ("What should the user see when X is down?" belongs on your refinement checklist permanently, next to "is there a speed expectation?") The seams you tested this page are exactly where Chapter 10's specialist fields — performance under load, security at the boundaries — will probe deeper; the map is now complete enough to carry you there.