Revolut and Google Cloud: A Payment Sales Outage Case Study

1. Read the official incident as evidence

Google places the London incident start at 07:08 BST on 20 October, identifying a power event in europe-west2-b. Its 13:44 BST notice reports recovery for most regional workloads as of 13:10 BST; the reviewed record contains no final all-clear. [1]

Worldpay’s first INC0697249 notice was published at 07:54 BST. Its 10:41 BST update names Revolut in connection with issuer-related transaction errors. At the check, Worldpay showed degraded authorisations but operational acquiring and funding/payouts. These are different service categories. [2][3]

Reported UK impact: keep the scope narrow

Reuters reported disruption to UK banking websites and mobile apps, and said Revolut’s status page showed unavailable or partially available services including card payments and ATM withdrawals. It also cited user reports concerning Lloyds, HSBC and Bank of Scotland, while warning that actual user impact may vary. [5]

AP separately reported disrupted online services at Lloyds, Halifax, HSBC and Revolut. These reports corroborate material UK impact. They do not establish that every merchant, terminal, acquirer or transaction failed, and they do not replace the live provider notices. [6]

2. Map the participants before explaining the problem

The issuer is the organisation responsible for the customer’s card account. The acquirer provides the merchant-facing acquiring relationship. A gateway helps route a payment request. Infrastructure providers supply technology that some payment participants depend on; a particular dependency must be evidenced, not assumed.

A payment authorisation and the later settlement or payout are different stages. An authorisation problem does not, by itself, establish that existing merchant payouts have stopped. Equally, an operational payout component does not prove that every attempted new card payment will succeed.

• Ask which participant and named service the source describes.
• Distinguish a cardholder issue, a merchant connection issue and a gateway report.
• Do not describe an issuer-specific report as a failure of every terminal or every acquirer.

3. Separate correlation from a verified explanation

The reviewed official sources do not establish that Google’s power event caused Revolut’s disruption. Two reports on the same morning are not proof of a shared dependency. Revolut’s retrieved UK status page indicated partial unavailability but did not provide sufficiently clear per-service detail for a precise card-payment conclusion. [4]

Practise labelling a statement: provider-reported, independently verified, inference or unknown. Even a trustworthy source can support a narrower claim than a dramatic headline suggests. Keep estimated restoration times separate from a confirmed resolution.

4. Practise a calm merchant conversation

Role-play a merchant saying: “A customer’s card failed. Is my machine broken?” A useful response is: “A decline alone cannot establish that. Which cards and error messages are affected, and what does your provider report?” This is a training example, not a diagnosis of any actual merchant’s system.

Then explain a suitable next step within your role: check the payment’s status, follow the provider’s support procedure and consider an already accepted alternative once any ambiguous first attempt is checked. Do not promise that a different card, provider or connection will work.

Never request full card numbers, security codes or public screenshots containing customer details. Use approved support channels and non-sensitive references. An incident article is not permission to collect private payment data.

5. Show good judgement in an interview

Prepare a two-minute explanation: identify the affected participant, cite the official notice and time, state the unresolved questions, then explain how you would communicate responsibly. Explain why operational acquiring and failed authorisations can appear in the same status report.

A strong answer also explains what you would avoid: inventing a root cause, presenting a tentative recovery estimate as a promise, blaming an individual terminal without evidence, or selling a replacement as guaranteed protection from upstream failures.

• Write one claim the notices verify and one they do not.
• Practise a concise update that includes a next check rather than an invented recovery time.
• Ask a colleague to challenge the limits of your explanation.

Keep learning after the incident

This case study teaches payment-chain reasoning and responsible sales communication. It is separate from merchant troubleshooting coverage on CardsMachines; the pages have distinct audiences and copy.

Facts retain their source-check timestamps. Material official developments can update this case study and its log. No job, earnings, interview, merchant savings or resilience outcome is guaranteed.

Learn the payment journey →

Practise discovery and closing →

Update log

• 20 Oct 2026, 14:41 UK time — 14:41 BST recheck: Google remained in recovery, Worldpay INC0697249 remained unresolved with Authorization & Payments degraded, and Revolut UK showed 30 services partially unavailable. Reuters and AP corroborated material UK banking disruption; universal merchant impact remains unsupported.
• 20 Oct 2026, 14:21 UK time — Reframed this canonical page as payment sales training: payment-chain roles, incident verification and interview practice. Merchant troubleshooting now has a separate CardsMachines article with its own canonical. Official factual snapshot remains checked at 14:09 BST.
• 20 Oct 2026, 14:09 UK time — Initial official-source verification: Google’s 13:44 BST recovery update, Worldpay’s unresolved Revolut-related incident and operational acquiring/funding components, and Revolut’s partial-unavailability page. Shared causation and individual terminal impact remain unconfirmed.