Offline payments and verification during power cuts.

01 / THE CONTEXT

Why are governments advising people to keep food and prepare for blackouts?

Because a disruption to electricity, water, communications or transport can interrupt ordinary life before help reaches everyone. Keeping modest supplies is a resilience measure. It is not, by itself, evidence that a government expects an imminent nationwide blackout.

The UK: a new campaign, not a new prediction

The Cabinet Office launched updated Be Ready advice on 22 October 2026, beginning a three-year public-awareness campaign. Its announcement points to severe weather and disrupted services, builds on guidance published since May 2024, and explains that household preparedness lets emergency responders prioritise people needing more support. The campaign centres on preparing for three days of disruption. Read the Cabinet Office announcement.

The government’s power-cut guidance says most outages are local and short, while longer regional outages, and unlikely national impacts, are possible. It recommends food that does not need cooking, drinking water, backup lighting and a small amount of cash if electronic payments fail. Read the UK power-cut guidance.

The USA: disaster preparedness and specific regional grid risks

US advice has a similar practical purpose. FoodSafety.gov recommends at least three days of food because disasters can interrupt supplies. NOAA’s hurricane guidance recommends food, water, medicines, cash and battery-powered equipment for a potentially prolonged aftermath. These are preparedness recommendations, not a dated forecast of a nationwide outage. FoodSafety.gov · NOAA hurricane preparedness.

Specific grid warnings must be read separately. For example, on 30 June 2026, the US Department of Energy issued time-limited orders for the Mid-Atlantic/PJM region ahead of forecast heat and peak demand. Those orders were scheduled to expire on 3 July. That is evidence of a particular regional reliability concern, not a current nationwide blackout notice. Read the dated DOE announcement.

02 / A NECESSARY DISTINCTION

Can digital payments work without the internet?

Some payment arrangements support offline collection or offline value transfer, but “offline” does not always mean “paid and settled”. The Federal Reserve distinguishes fully offline arrangements from hybrid systems that still require later connectivity for authorisation or settlement. Federal Reserve analysis of offline payments.

Payment providers impose their own limits. Adyen, for example, documents support checks, transaction limits and later forwarding, and warns that store-and-forward transactions can still be declined. No extra signature from AffixIO removes that risk. Adyen offline-payment documentation.

Where AffixIO fits in an offline payment workflow

AffixIO can be integrated before acceptance to check a locally available permission or policy and retain signed evidence of the result. An application might bind an approval to a merchant, amount, currency, entitlement reference, expiry and policy version. The implementer must define and enforce that binding; a generic “yes” is not permission for any purchase.

The payment provider or issuer still handles money movement. Keep separate states such as locally approved, pending provider authorisation, settled and declined. Never display “paid” solely because a proof or signature verifies. This is an integration architecture, not a claim that AffixIO is an acquiring bank, card processor, e-money issuer or universally compatible offline checkout product.

03 / WHAT EXISTS

What can AffixIO realistically do offline?

The public affixio 2.0.4 package contains local proving, signing, verification, replay, carrier and usage-journal components. They are building blocks, not a complete disaster-response system. The table distinguishes released components from integration work.

Proof modes matter. The SDK’s HMAC path is not zero-knowledge, and a party holding its shared verification secret can also forge that class of proof. Independent offline verifiers should use pinned public-key attestation verification, with exact proof/context binding where applicable, or an appropriate supported zero-knowledge workflow. UltraHonk is a separate path with circuit, runtime and entitlement requirements. Do not distribute the issuer’s HMAC or signing secret to a till or scanner.

ML-DSA is the signature family standardised in NIST FIPS 204. Its role here is authenticity and integrity under a trusted key. It does not prove that a source record was accurate, that goods were delivered, or that an entire product is government-certified. NIST FIPS 204 · SDK documentation.

04 / PRACTICAL APPLICATIONS

Six useful systems an organisation could build

These are proposed applications of the SDK, not claims of existing government deployments, approved payment integrations or completed emergency-service products.

1. Food, water and essential-supply entitlements

A charity, council or employer could pre-issue a site-bound entitlement from an authorised allocation list. A powered local verifier checks the issuer and validity, then records redemption without exposing a full household record. The programme still needs stock, accessible alternatives, duplicate controls and an accountable issuer. A person without a smartphone must not be excluded by the design.

2. Bounded merchant continuity

A merchant could combine an approved payment provider’s offline mode with a separate local policy check: permitted purchase type, local exposure ceiling and an expiry. AffixIO can help evidence that check. The acquirer’s rules and later authorisation determine payment success. Do not retain card numbers or other sensitive payment data in an AffixIO evidence payload.

3. Staff and contractor permissions

A site could verify a previously issued, short-lived work authorisation using cached trust information. The local application must check the relevant site and action. It must not equate a badge with unrestricted physical access, override fire-egress requirements or bypass safety procedures. High-risk privileges may need to stop when status cannot be refreshed.

4. Logistics handover records

A depot could sign a dispatch or receipt record while disconnected and reconcile it when systems recover. Separate signatures for dispatch and receipt make responsibility clearer. A signature authenticates the recorded claim; it does not independently prove that a parcel arrived or that its contents and temperature were correct.

5. Evidence for controlled local automation

An on-site application or locally running AI agent could check cached, bounded permissions before an action and retain a decision receipt. Its models, tools and dependencies must also be available locally. AffixIO does not make a cloud-only agent work offline, and unavailable permission data should not turn into an automatic approval.

6. Post-incident review and reconciliation

Local decision records can help compare what was authorised, what a device recorded and what a downstream service later confirmed. This can support investigation, exception handling and operational learning. It is evidence for review, not a guarantee of legal admissibility, regulatory compliance or an unalterable historical timeline.

05 / THE OPERATING MODEL

Prepare online. Verify locally. Reconcile deliberately.

1. Before the outage: provision the trust

   Install and test the runtime, circuits and verifier. Distribute trusted issuer keys and policy versions through an authenticated process. Cache only authorised data, record its age, define an offline validity window and allocate exposure by device or site. Test batteries, storage, timekeeping, key recovery and licensing behaviour before relying on them.

2. During the outage: make a bounded decision

   Check signature, issuer, exact action, resource, expiry, local status and repeat use. Atomically record a permitted consumption before releasing a controlled resource. Keep a signed receipt with the policy version and known freshness limits. If trust, time or journal integrity fails, stop that automated approval and use the organisation’s documented fallback.

3. After the outage: resolve, do not assume

   Refresh trust and revocation information. Forward queued evidence using idempotent processing; compare issuer, device and payment-provider records. Separate duplicates, declines and uncertain outcomes for review. Record settlement or delivery only from the relevant confirming system. Preserve the original offline decision and its limitations.

Local verification removes a network dependency from a specific check. It does not remove all dependencies from a service. A printer, scanner, local database, router or terminal that has lost power can still stop the workflow.

06 / NON-NEGOTIABLE LIMITS

The risks an honest offline design must address

Double spending across disconnected devices

Two isolated verifiers can both accept the same otherwise valid entitlement if neither knows the other has consumed it. Local replay protection cannot solve that global coordination problem. Consider site-bound vouchers, partitioned allocations, hardware-backed counters or conservative loss limits, then validate the chosen threat model. Later reconciliation can discover a conflict; it cannot undo goods already handed over.

Revocation freshness and compromise

A disconnected verifier can reject a key it already knows is revoked, but cannot learn a newly issued revocation without receiving an update. Set an explicit maximum age for trust data, use short-lived permissions and define which actions must wait for a fresh check. A signed timestamp is not, on its own, independent evidence of when a compromised key was used.

Clock rollback, lost state and concurrent use

Expiry checks depend on trustworthy time. Reboots, restored backups, multiple worker processes and interrupted writes must not reset consumption state. The default in-memory replay store is not durable across restarts. Choose a persistent, atomic store for the deployment, and test recovery and concurrent redemption. A signed hash chain detects certain modifications, but needs externally protected checkpoints to make rollback or truncation detectable beyond local state.

Offline data is a snapshot

A perfectly valid signature can cover outdated information. Record the source and policy versions and distinguish “valid against the last trusted snapshot” from “confirmed current”. A live database lookup, fresh bank balance, newly revoked credential or current sanctions check cannot be conjured from a disconnected machine.

Power, privacy and operational ownership

Use powered, provisioned devices with sufficient battery life; keep physical and paper alternatives. Encrypt sensitive local storage and restrict access separately from signing. Keep personal details out of portable evidence where they are not necessary. Payment, public-service and sector-specific obligations still apply, and the implementing organisation remains responsible for them.

07 / BUILD WITH EVIDENCE

Start with one narrow offline pilot

Choose a non-critical workflow with an identified issuer, a defined offline window and a clear owner of losses and exceptions. A site-bound supply entitlement is a more controlled starting point than a claim to replace an entire payment system.

• Define the claim: what exact action, item, site, amount or entitlement does a successful check authorise?
• Choose the evidence: identify the authoritative source, snapshot age and fields that must be signed together.
• Separate authorities: keep signing keys on the issuer; provision only trusted public keys to independent verifiers.
• Set the stop conditions: expired evidence, stale trust data, unknown keys, unavailable policy, full storage and corrupt state must have explicit handling.
• Protect usage state: test a repeat scan, simultaneous scans, process restart, power interruption and restore from backup.
• Prove the offline path: disconnect networking, including DNS and local services that may secretly depend on the internet. Test after a cold start, not only a warm cache.
• Test recovery: include a revoked key, duplicate upload, provider decline and reconciliation conflict. Keep approvals distinct from settlement.
• Measure and review: capture battery endurance, verification latency on target hardware, storage use, false rejects and unresolved records. Obtain the required security, accessibility, operational and payment-provider reviews.

What we checked for this guide

We inspected the published affixio 2.0.4 package and ran 11 focused helper checks using synthetic data on 26 October 2026: pinned-key verification, changed-payload rejection, wrong-key rejection, refusal to trust an embedded key alone, locally known revoked-key rejection, fresh/repeated/expired replay IDs, first/second local consumption, and journal integrity. The test disabled JavaScript fetch and used no live identities or payments.

These tests are not a full network-isolation test, independent security audit, payment certification, multi-device anti-double-spend test or proof of an emergency deployment. Read the machine-readable test results. For a real deployment, run the broader checklist above on the actual hardware and application.

08 / BUILD IT WITH AFFIXIO

The SDK is the foundation. We can build the system around it.

You do not need to assemble every part yourself. AffixIO can scope, design and build the application components around its verification technology, turning an agreed resilience requirement into a tailored implementation.

Depending on the project, that work can include entitlement issuance, operator and verifier applications, connections to existing business systems, durable usage records, reconciliation workflows, administration tools and deployment testing. We start by establishing what must keep working, what can safely wait, and which dependencies sit outside the system.

The scope and cost depend on your existing infrastructure, hardware, security requirements, third-party integrations and support needs. Any payment-provider approvals, regulatory obligations, independent assessments or external service costs must be identified and assigned explicitly. A custom build does not remove the offline limits described above or guarantee payment settlement.

09 / DIRECT ANSWERS

Offline payments and verification FAQ

10 / CHECK THE EVIDENCE

Sources, technical references and review scope

Official guidance checked on 26 October 2026. Publication dates are distinguished from this review date. This page is a technical resilience guide, not an emergency alert, household safety manual, financial recommendation or government-endorsed product listing.

1. UK Cabinet Office: updated household preparedness campaign — published 22 October 2026.
2. UK Be Ready: power cuts — official preparedness and response guidance.
3. US FoodSafety.gov: food safety in a disaster or emergency — emergency food and water planning.
4. NOAA: assemble disaster supplies — hurricane preparedness and loss of utilities.
5. US Department of Energy: Mid-Atlantic grid orders — published 30 June 2026; scheduled expiry 3 July 2026.
6. Federal Reserve: offline payments, reliability and resiliency — analysis published 16 August 2024; not an AffixIO endorsement.
7. Adyen: offline payments — provider-specific behaviour and risks; not an integration or partnership claim.
8. NIST FIPS 204: ML-DSA signature standard — algorithm standard, not product validation.
9. Published affixio 2.0.4, public SDK source and implementation documentation — technical basis for the capability discussion.

Read this guide as Markdown · Machine-readable summary · Structured facts and boundaries · Download the pilot checklist

Built around evidence, not fear. Government advice explains why to prepare; a tested implementation determines what your service can safely keep doing.