DEV Community: Tom Wang

ACH vs RTP vs FedNow vs Fedwire: US Rails Guide

Tom Wang — Wed, 07 Oct 2026 07:43:07 +0000

Of the eight pages Google currently ranks for "ACH vs RTP vs FedNow", five quote a FedNow limit that has been wrong since November 2025, two still say the RTP cap is $1m, and one claims FedNow only runs between 7am and 7pm. Not one of them names an ISO 20022 message, shows an API payload, or explains why a FedNow "return" is a favour rather than a right.

This guide is the version I wanted when I first had to pick a rail per payout for a US treasury product. It covers the four domestic rails an engineer actually touches: ACH, RTP, FedNow and Fedwire, with CHIPS in a footnote. For each one: what the limit is and when it last changed, when the money moves, what messages carry it, what happens when it goes wrong, which legal regime governs the loss, and how the main US payment APIs expose the choice. It is the US counterpart to my Faster Payments vs Bacs vs CHAPS guide, and the mapping between the two is at the end for UK readers.

What Is the Difference Between ACH, RTP, FedNow and Fedwire?

All four settle in US dollars across accounts at the Federal Reserve. Three are operated by the Fed (FedACH, FedNow, Fedwire), one by a bank-owned private company (RTP, The Clearing House), and ACH has a second private operator, EPN, also run by The Clearing House. Everything else differs.

	ACH	RTP	FedNow	Fedwire Funds
Operator	FedACH and EPN under Nacha rules	The Clearing House	Federal Reserve	Federal Reserve
Speed	Next banking day, or same day in three windows	Seconds, 24/7/365	Seconds, 24/7/365	Minutes, 22 hours a day on business days
Per-payment cap	$1m same-day (to $10m on 17 Sep 2027); none for standard	$10m (since 9 Feb 2025)	$10m network max (Nov 2025); $100k default per bank	None
Settlement	Deferred net, four times a banking day	Real-time, prefunded joint account at the Fed	Real-time gross, Fed master accounts	Real-time gross, Fed master accounts
Message format	Nacha fixed-width records	ISO 20022	ISO 20022	ISO 20022 since 14 Jul 2025
Pull payments	Yes (debits)	No, Request for Payment only	No, Request for Payment only	No, drawdown request only
Reversible	Yes, return codes	No	No	No
2025 volume	35.2bn payments, $93tn	447m payments, $1.45tn	8.4m payments, $853bn	217m transfers, roughly $1.15 quadrillion

Read the full article on tomcn.uk →

About the Author

I'm Tom Wang, an AI Developer & Fintech Developer — building AI agents, crypto payment infrastructure, and cross-border payout systems with Rust, Go, and TypeScript. Based in London, UK.

Currently open to new opportunities in fintech, crypto payments, and AI agent engineering.

Portfolio | LinkedIn | GitHub | Email

Roughrider Coin on Solana: Deposit or Stablecoin?

Tom Wang — Sun, 04 Oct 2026 09:51:17 +0000

Fiserv's press release on 1 October calls Roughrider Coin a "dollar-backed stablecoin". Bank of North Dakota, the state bank whose name is on the coin, calls it "a U.S. dollar-backed token deposit designed exclusively for bank-to-bank transactions". Under the GENIUS Act those two descriptions are mutually exclusive, and which one is right decides who regulates it.

The launch itself is real. Fiserv's Digital Asset Platform went into production with Roughrider as its "first live use case", running on Solana with VersaBank as issuer and Fireblocks doing custody. The headlines around it are less reliable. TechTimes ran "Fiserv Stablecoin Platform Activates 10,000 Banks" with "400ms settlement" replacing "overnight ACH". All three claims are wrong, and why they are wrong is the useful part.

How Many Banks Are Live on Fiserv's Digital Asset Platform?

Four. Fiserv's release says more than 90 North Dakota banks and credit unions take part. BND told The Dakotan that the token moved from testing into production with four pilot institutions, and that access to the wider group "is being introduced gradually" with no date for expansion. The 10,000 figure is Fiserv's whole client base, which the TechTimes body text concedes even though the headline does not.

(The Dakotan dates the production move to 3 October, not 1 October.) BND's Roughrider page adds that the public cannot hold the token at all. It is interbank only, voluntary, and approved as a pilot by the North Dakota Industrial Commission.

Party	Role
Bank of North Dakota	Sponsor and governance, "oversight role"
VersaBank USA, N.A.	Issuer: minting, burning, custody, reserve management
Fiserv	Platform; banks access it through Commercial Center, its commercial online banking product
Fireblocks	MPC wallets, tokenisation, automated policy controls
Solana	Transaction processing

VersaBank USA holds an OCC national bank charter, acquired through the purchase of Stearns Bank Holdingford in Minnesota in 2024. That detail is what makes the "deposit" reading plausible.

Is Roughrider Coin a Stablecoin or a Tokenised Deposit?

The GENIUS Act (P.L. 119-27, signed 18 July 2025) defines "payment stablecoin" and then carves out of it, in §2(22)(B)(ii), any deposit under the Federal Deposit Insurance Act, "including a deposit recorded using distributed ledger technology". A tokenised deposit stays inside bank regulation. A payment stablecoin needs a permitted issuer, 1:1 reserves in the assets the Act lists, and monthly reserve disclosure.

Read the full article on tomcn.uk →

About the Author

I'm Tom Wang, an AI Developer & Fintech Developer — building AI agents, crypto payment infrastructure, and cross-border payout systems with Rust, Go, and TypeScript. Based in London, UK.

Currently open to new opportunities in fintech, crypto payments, and AI agent engineering.

Portfolio | LinkedIn | GitHub | Email

SEPA Direct Debit Core vs B2B: Developer Guide

Tom Wang — Sat, 03 Oct 2026 08:18:55 +0000

Stripe, Adyen and GoCardless all support SEPA Direct Debit, but none of them will collect under the B2B scheme, and Mollie doesn't document it either. That matters more than it sounds. B2B is the version where the payer cannot claw the money back, and if you sell to businesses you have probably been told it exists, that it is safer, and that you should "just switch it on". Through a PSP API, in 2026, you can't.

The guides that rank for "SEPA Direct Debit Core vs B2B" are written for finance teams: Core is for consumers, B2B is for companies, B2B has no refund. That's accurate, and it won't help you write the code that handles an MD06 return seven weeks after you shipped the goods. This guide works from the European Payments Council's 2025 rulebooks and implementation guidelines (in force since 5 October 2025), Regulation (EU) 260/2012 and PSD2, and the current developer docs of four PSPs.

What Is the Difference Between SEPA Direct Debit Core and B2B?

They are two separate EPC schemes with two separate rulebooks. They share the mandate model and the ISO 20022 messages, and the differences sit almost entirely in who can reverse a collection and when.

	SDD Core	SDD B2B
Rulebook	EPC016-06, 2025 v1.0	EPC222-07, 2025 v1.0
Who can be the payer	Consumers and businesses	Non-consumers only
Refund of an authorised debit	Yes, 8 weeks, no questions asked	No
Refund of an unauthorised debit	13 months	13 months, not recoverable from the creditor's PSP
Debtor bank checks the mandate	No	Yes, against the debtor's confirmation, every collection
Latest presentation	D-1 inter-PSP business day	D-1 inter-PSP business day
Return window (debtor PSP)	D+5 inter-PSP business days	D+3 inter-PSP business days
PSP API support (Stripe, Adyen, GoCardless)	Yes	No

Core accepts business accounts too. Stripe's docs spell it out: the Core scheme "supports both business and personal bank accounts". So the choice is never "Core for consumers, B2B for companies". The real choice is whether you can get your business customers to do the extra work B2B requires, and whether your bank will sponsor you for it.

How Long Does a SEPA Direct Debit Take? D-1, D+5 and the 14-Day Window

Read the full article on tomcn.uk →

About the Author

I'm Tom Wang, an AI Developer & Fintech Developer — building AI agents, crypto payment infrastructure, and cross-border payout systems with Rust, Go, and TypeScript. Based in London, UK.

Currently open to new opportunities in fintech, crypto payments, and AI agent engineering.

Portfolio | LinkedIn | GitHub | Email

Card Auth Expiry: Visa vs Mastercard Capture Rules

Tom Wang — Mon, 28 Sep 2026 07:16:55 +0000

Four major PSPs give four different answers to one question: how long can I hold a customer-initiated Visa authorisation online before I have to capture it? Stripe says 7 days, Braintree 8, Adyen 10, and Checkout.com says 7 on one page and 10 on another. Visa's own rulebook says 10. If your order service has CAPTURE_DEADLINE_DAYS = 7 somewhere in a config file, that constant came from one PSP's docs page, not from the card schemes, and it is wrong for about half the transaction types you probably process.

Most of the pages ranking for "how long does an authorization hold last" answer with a range: "a few days to a week", "up to 30 days". This guide works from the primary sources instead: the Visa Core Rules dated 18 April 2026, Mastercard's Transaction Processing Rules (December 2025 edition), the American Express merchant rules, and the API docs of Stripe, Adyen, Checkout.com and Braintree as they stand in September 2026.

How Long Does a Card Authorisation Hold Last?

It depends on three things: the scheme, the authorisation type you asked for, and who initiated the payment. The scheme sets the rule. Your PSP then usually applies a shorter window of its own, and the issuer releases the hold on the cardholder's side on its own schedule.

The short version, by scheme rule:

Scheme	Type	Validity
Visa	Customer-initiated, card-not-present	10 days
Visa	Card-present, and all merchant-initiated	5 days
Visa	Estimated auth at lodging, cruise, vehicle rental	30 days
Visa	Extended authorisation (CIT, card-not-present)	30 days
Mastercard	Final authorisation	7 days
Mastercard	Pre-authorisation	30 days
Amex	Standard charge	7 days
Amex	Estimated auth, lodging / car rental / cruise	Duration of stay or rental

Discover publishes no public rulebook. Stripe and Adyen both document 7 to 10 days for card-not-present, so treat it as 7 unless your acquirer tells you otherwise.

Visa Authorisation Validity Periods Since April 2024

On 13 April 2024 Visa merged two separate clocks, authorisation validity and the clearing deadline, into one "authorization-to-clearing time frame" (Visa Business News AI13522, October 2023). The current numbers sit in Table 5-12 of the Core Rules, section 5.7.3.5. Every window starts from the date of the approval:

Read the full article on tomcn.uk →

About the Author

I'm Tom Wang, an AI Developer & Fintech Developer — building AI agents, crypto payment infrastructure, and cross-border payout systems with Rust, Go, and TypeScript. Based in London, UK.

Currently open to new opportunities in fintech, crypto payments, and AI agent engineering.

Portfolio | LinkedIn | GitHub | Email

Faster Payments vs Bacs vs CHAPS: UK API Guide

Tom Wang — Sun, 27 Sep 2026 07:17:07 +0000

From November 2026, the Bank of England will reject any CHAPS payment whose creditor address is fully unstructured. If your payout service builds addresses by concatenating five free-text lines into AdrLine, those payments will fail at the scheme in about eight weeks, and your bank or BaaS provider will probably not warn you first.

None of the pages currently ranking for "Faster Payments vs Bacs vs CHAPS" mentions this. They are treasury explainers: Faster Payments is quick, Bacs is cheap, CHAPS is for houses. All true, and no help if you are writing the code that sends, tracks and reconciles money across all three. This guide covers what an engineer actually needs: message formats, limits, cut-offs, settlement, return handling, fraud liability, and how the main UK payment APIs decide which rail your payment takes.

What Is the Difference Between Faster Payments, Bacs and CHAPS?

All three are UK sterling interbank schemes that settle in central bank money at the Bank of England. Everything else about them differs, and each difference has a consequence for how you design a system.

	Faster Payments (FPS)	Bacs	CHAPS
Operator	Pay.UK (Vocalink infrastructure)	Pay.UK (Vocalink infrastructure)	Bank of England
Speed	Seconds, 24/7/365	3 UK banking days	Same day, within RTGS hours
Scheme limit	£1m per payment	£20m per item	None
Settlement	Deferred net, three times per banking day	Deferred net, once per day	Real-time gross (RTGS)
Message format	ISO 8583	Standard 18 fixed-width files	ISO 20022 (pacs.008, pacs.009, pacs.004)
Pull payments	No	Yes, Direct Debit	No
APP fraud reimbursement	Yes, up to £85,000	No	Yes, up to £85,000
2025 volume	5.55bn payments, £4.84tn	6.86bn payments, £6.05tn	53.25m payments, £93.9tn

The volume row explains the rest. Bacs still moves more payments than Faster Payments, mostly because 5.03bn of its 6.86bn items in 2025 were Direct Debits. CHAPS moves under 1% of the payments by count and roughly 90% of the value across the three schemes, at an average of £1.76m per payment. Pay.UK's 2025 annual statistics are the source for all three rows.

Faster Payments Limits, Settlement and Timing in 2026

The Faster Payments scheme limit is £1m per payment. It was raised from £250,000 on 8 February 2022 and has not changed since. That is a scheme ceiling, not what your customer gets: banks set their own limits by channel and account type, so a personal online payment at one high-street bank tops out at £25,000 while business channels elsewhere go to the full £1m. If you surface a limit in your UI, fetch it from your provider rather than hardcoding the scheme figure.

Read the full article on tomcn.uk →

About the Author

I'm Tom Wang, an AI Developer & Fintech Developer — building AI agents, crypto payment infrastructure, and cross-border payout systems with Rust, Go, and TypeScript. Based in London, UK.

Currently open to new opportunities in fintech, crypto payments, and AI agent engineering.

Portfolio | LinkedIn | GitHub | Email

Apple Pay Token Decryption vs Google Pay ECv2

Tom Wang — Sat, 26 Sep 2026 07:20:29 +0000

Apple's own reference page for decrypting an Apple Pay token currently gets the key derivation wrong. The KDF table lists the hash function where the shared secret should be, and it has dropped the id-aes256-GCM algorithm ID bytes altogether; the archived version of the same page has the correct values. If you are building a decryptor from the live docs, you will get a key that never opens the ciphertext, and nothing in the error will tell you why.

That is the level most "decrypt Apple Pay token" guides stop above. They show you a library call, or a PSP's CSR upload screen, and move on. This guide covers the actual formats for Apple Pay (EC_v1 and RSA_v1) and Google Pay (ECv2), the signature checks people skip, the certificate rotation rules that cause outages, and the more important question: whether you should be decrypting at all.

What Is Inside an Apple Pay Payment Token?

When the payment sheet completes, PKPayment.token.paymentData (or the ApplePayPaymentToken on the web) hands you a JSON object with four keys:

{
  "version": "EC_v1",
  "data": "<base64 ciphertext>",
  "signature": "<base64 detached PKCS #7>",
  "header": {
    "ephemeralPublicKey": "<base64 X.509 key>",
    "publicKeyHash": "<base64 SHA-256 of your cert's public key>",
    "transactionId": "<hex, generated on device>",
    "applicationData": "<hex SHA-256, optional>"
  }
}

version is EC_v1 almost everywhere. Apple says other regions use RSA_v1 "if ECC encryption is unavailable due to regulatory concerns", and its March 2026 certificate technote (TN3206) makes the mapping clear without quite saying it: the Payment Processing CSR is a 256-bit ECC key globally and a 2048-bit RSA key for China mainland. An RSA_v1 header carries wrappedKey instead of ephemeralPublicKey.

publicKeyHash matters more than it looks. It is the only field that tells you which of your private keys the token was encrypted to, and you will need it during every certificate rotation.

How to Decrypt an Apple Pay Token (EC_v1)

The flow for EC_v1 is ECDH, then a single-pass NIST SP 800-56A concatenation KDF, then AES-GCM:

Select the key. Match header.publicKeyHash against the SHA-256 of each Payment Processing certificate's public key you hold.
Agree a secret. ECDH between your private key and ephemeralPublicKey. Apple only says "256-bit ECC key pair"; every open-source decryptor treats it as P-256.
Derive the key. SHA-256 over counter (0x00000001) || Z || AlgorithmID || PartyUInfo || PartyVInfo, where:
- Z is the ECDH shared secret
- AlgorithmID is the byte 0x0D followed by the ASCII string id-aes256-GCM (the 0x0D is a length prefix: 13 characters)
- PartyUInfo is the ASCII string Apple
- PartyVInfo is the SHA-256 of your merchant identifier, either hashed from the UID in the certificate subject or hex-decoded from the extension at OID 1.2.840.113635.100.6.32
Decrypt. AES-256-GCM over data, IV of 16 zero bytes, no associated data. The last 16 bytes of data are the GCM tag.

Read the full article on tomcn.uk →

About the Author

I'm Tom Wang, an AI Developer & Fintech Developer — building AI agents, crypto payment infrastructure, and cross-border payout systems with Rust, Go, and TypeScript. Based in London, UK.

Currently open to new opportunities in fintech, crypto payments, and AI agent engineering.

Portfolio | LinkedIn | GitHub | Email

Card Decline Codes: Visa vs Mastercard Retry Rules

Tom Wang — Fri, 25 Sep 2026 07:16:59 +0000

Visa now lets a merchant retry a soft-declined card up to 20 times in 30 days, not 15. The figure sits in Table 7-2 of the Visa Core Rules dated 18 April 2026, and Adyen's own retry documentation still says 15. If the incumbent guides and one of the biggest acquirers disagree on the headline number, your retry logic is probably keyed on something older still.

Most of the pages that rank for "card decline codes" are glossaries: a list of two-digit codes with a sentence each. That is the least useful way to think about them. A decline is three separate signals (the ISO 8583 response code, a scheme-level retry category or advice code, and whatever your PSP normalises them into) and the retry rules attach to the first two, not the third. This guide works from the scheme rules and the four PSP APIs as they stand in September 2026.

What Do Card Decline Codes Actually Mean?

The issuer's answer travels back in ISO 8583 Data Element 39, the response code. 00 is approved. Everything else is a reason for not approving, and the two-character value space is shared across schemes without being fully standardised by them. Visa publishes its meanings in the Core Rules. Mastercard publishes its own, plus a second signal: the Merchant Advice Code, which tells you what to do next rather than why it failed. Secondary sources consistently place the MAC in DE 48 subelement 84; Mastercard's interface specification that would confirm it sits behind a login.

The trap is that the same code can mean different things on different networks. Code 65 is the clearest example. On Visa it is "Exceeds withdrawal frequency limit", a Category 2 soft decline. On Mastercard in the UK and EEA, issuers use 65 to demand strong customer authentication, and Stripe's docs note that its authentication_required decline on Mastercard used to surface as withdrawal_count_limit_exceeded because some issuers had not updated their systems. If you map raw codes without the scheme alongside them, you will misroute a slice of your SCA traffic.

Visa Decline Categories in 2026: 20 Retries, Not 15

Visa sorts every decline response into four categories. Issuers must "send to VisaNet the Decline Response code that most accurately reflects the reason for the decline", and merchants are bound by the category's reattempt limit.

Category	Meaning	Codes (Visa Core Rules, Apr 2026)	Merchant limit
1	Issuer will never approve	04, 07, 12, 14, 15, 41, 43, 46, 57, R0, R1, R3	Never retry
2	Issuer cannot approve at this time	03, 19, 39, 51, 52, 53, 59, 61, 62, 65, 75, 78, 83, 86, 91, 93, 96, 5C, 9G, N3, N4, Z5	20 attempts in 30 days
3	Data quality, revalidate	54, 55, 82, 6P, N7; in Europe and CEMEA also 70 and 1A	20 attempts in 30 days
4	Generic	All other decline codes, including 05	20 attempts in 30 days

Read the full article on tomcn.uk →

About the Author

I'm Tom Wang, an AI Developer & Fintech Developer — building AI agents, crypto payment infrastructure, and cross-border payout systems with Rust, Go, and TypeScript. Based in London, UK.

Currently open to new opportunities in fintech, crypto payments, and AI agent engineering.

Portfolio | LinkedIn | GitHub | Email

AP2 vs ACP vs x402: Who Holds the Credential?

Tom Wang — Mon, 14 Sep 2026 07:16:33 +0000

In ACP, the agent platform vaults the card and hands the merchant a token capped at the checkout total. In AP2, a Credential Provider keeps the card and the user signs an SD-JWT that says what the agent may do with it. In x402 there is no card and nothing to vault: the payer's wallet signs a one-off USDC transfer and a facilitator puts it on-chain.

Those are three different answers to the question of who holds the money. Most pages ranking for "AP2 vs ACP vs x402" skip that and describe layers. Several, one earlier piece of mine among them, still explain AP2 with Intent and Cart Mandates, which the v0.2 spec replaced in April 2026.

What Is the Difference Between AP2, ACP and x402?

They standardise different things. ACP is a merchant checkout API. AP2 is a format for signed evidence that a user authorised an agent. x402 is an HTTP handshake for paying on a stablecoin rail. You can use all three in one flow, and the specs increasingly expect you to.

	AP2	ACP	x402
Governed by	FIDO Alliance (donated by Google, 28 Apr 2026)	OpenAI and Stripe	x402 Foundation, Linux Foundation (operational 14 Jul 2026)
Current version	v0.2	`2026-04-17`	Spec v2
What it defines	Mandates and receipts	Checkout sessions, delegated payment, product feeds	402 challenge, payment payload, facilitator API
Who holds the credential	Credential Provider	Agent platform's PSP or vault	Payer's own wallet
Proof of authorisation	User-signed SD-JWT mandate	Single-use token with an `allowance`	EIP-3009 signature per payment
Money moves on	Any rail the processor supports	The merchant's existing card processor	On-chain, e.g. USDC on Base (`eip155:8453`)
Dispute path	Evidence only, resolution out of scope	Normal chargeback via merchant of record	None in the spec
Transport	Extension to A2A, MCP and UCP	REST, plus MCP from `2026-04-17`	HTTP headers, A2A, MCP

The x402 Foundation launched with 40 members, including Adyen, American Express, Google, Mastercard, Shopify, Stripe and Visa. That membership overlaps almost entirely with AP2's and ACP's backers, which tells you nobody expects one protocol to win outright.

How Does ACP Checkout Work in 2026?

The merchant implements five endpoints:

Read the full article on tomcn.uk →

About the Author

I'm Tom Wang, an AI Developer & Fintech Developer — building AI agents, crypto payment infrastructure, and cross-border payout systems with Rust, Go, and TypeScript. Based in London, UK.

Currently open to new opportunities in fintech, crypto payments, and AI agent engineering.

Portfolio | LinkedIn | GitHub | Email

Variable Recurring Payments API: The Hard Parts

Tom Wang — Sun, 06 Sep 2026 07:22:45 +0000

Several of the guides that currently rank for "variable recurring payments API" list MaximumCumulativeAmount and MaximumCumulativeNumberOfPayments as VRP control parameters. Neither field exists. I checked the published OpenAPI definitions at v3.1.10, v3.1.11 and v4.0.1, and there are zero occurrences in any of them.

That is roughly the state of VRP documentation outside the specification itself: thorough on sweeping versus non-sweeping, silent on everything that actually costs you a sprint.

What Is the Variable Recurring Payments API and Who Has to Offer It?

A VRP is one long-lived consent that authorises many payments underneath it, each validated against limits the customer set when they authenticated. It is not a payment message repeated on a timer. It is a mandate held at the bank, with the bank enforcing the caps.

There are two flavours, and the split is regulatory rather than technical. The CMA mandated that the CMA9 offer open access to the VRP API for sweeping, which means moving money between accounts belonging to the same person. Open Banking Limited states the other half just as plainly: non-sweeping VRPs were not mandated by the CMA, so the CMA9 are not obliged to provide them. Six of the nine (HSBC, Santander, NatWest, Nationwide, Lloyds and Barclays) had sweeping live by the end of 2022. Sweeping is now a real rail, running 7.73 million payments in June 2026, up 6.7% on the month.

Commercial VRP is the one everybody writes about, and it arrived through a scheme rather than a mandate. The UK Payments Initiative went live on 2 June 2026, one quarter later than the Q1 2026 the FCA and PSR had signalled in December 2025.

The current standard is v4.0.1, released 1 April 2026, base path /open-banking/v4.0/pisp. The CMA9 were required to be on v4.0 by the end of March 2025, and running OBL 4.0 in production is a prerequisite for UKPI participation. If you are still building against 3.1.x, you are building against a migration target.

What Endpoints Does the VRP API v4.0.1 Expose?

Six paths, eight operations, and one of them is a trap.

Method	Path	Purpose
`POST`	`/domestic-vrp-consents`	Create the mandate
`GET`	`/domestic-vrp-consents/{ConsentId}`	Read mandate + status
`DELETE`	`/domestic-vrp-consents/{ConsentId}`	Revoke
`PUT`	`/domestic-vrp-consents/{ConsentId}`	Version migration only
`POST`	`/domestic-vrp-consents/{ConsentId}/funds-confirmation`	Balance check
`POST`	`/domestic-vrps`	Execute a payment
`GET`	`/domestic-vrps/{DomesticVRPId}`	Payment status
`GET`	`/domestic-vrps/{DomesticVRPId}/payment-details`	Detailed status history

Read the full article on tomcn.uk →

About the Author

I'm Tom Wang, an AI Developer & Fintech Developer — building AI agents, crypto payment infrastructure, and cross-border payout systems with Rust, Go, and TypeScript. Based in London, UK.

Currently open to new opportunities in fintech, crypto payments, and AI agent engineering.

Portfolio | LinkedIn | GitHub | Email

Rust's $350k Bet and an 86-Minute Attack

Tom Wang — Fri, 28 Aug 2026 09:23:47 +0000

At 07:15 UTC on 20 August, someone published arrayref 0.3.10 to crates.io. It was live for 86 minutes, picked up about 2,285 downloads, and every single one of them executed attacker-controlled code on the machine doing the build. That code ran before a single line of the project itself had compiled.

arrayref has 250,376,732 lifetime downloads. Fewer than 10% of its normal daily installs touched the poisoned version. The reason is unglamorous and worth sitting with: most teams had a Cargo.lock pinning 0.3.9, so Cargo never went looking for anything newer.

Six days later the Rust Project announced its first Maintainers in Residence, directing $350,000 at six people for at least twelve months. Both stories landed in the same week, both are about who keeps Rust standing up, and the gap between them is the thing I want to talk about. As a fintech developer who has shipped Rust into payment systems, my read is that the funding is genuinely good and does almost nothing about the attack that preceded it.

What Actually Ran on Those Build Machines

The mechanics are worth spelling out, because most coverage stopped at "malicious crate."

The compromised arrayref 0.3.10 did not contain malware. It added one line to its manifest:

[dependencies.proc-macro1]
version = "1.0.107"

proc-macro1 is a typosquat of proc-macro2, one of the most-depended-on crates in the ecosystem. The real payload lived in proc-macro1-1.0.107/build.rs. Because Cargo compiles and runs build scripts for every crate in the graph, it never mattered that arrayref didn't call a single function from it. Resolving the dependency was enough to detonate.

The build script reassembled its command-and-control address from base64 fragments (23.254.165.112, port 9089 for the payload, 443 for the beacon), then installed a certificate verifier that returned success for everything it was shown. That let it pull a binary over TLS from a raw IP with a self-signed certificate without a warning. It selected a platform-specific payload (rust-crate_0.1.0 for Linux x86_64 through rust-crate_0.4.0 for macOS ARM64), wrote it to /tmp/rust-setup, chmoded it, and spawned it detached with all streams sent to null.

The Windows path is the part that tells you these people had done this before. Cargo puts child processes in a job object, so they die when the build finishes. The attacker wrote a PowerShell script to %TEMP%\rust-setup.ps1 and launched it through a VBScript wrapper under wscript.exe with CREATE_NO_WINDOW. The comment in the source said it plainly: this escapes Cargo's job object. The process outlives the build.

Read the full article on tomcn.uk →

About the Author

I'm Tom Wang, an AI Developer & Fintech Developer — building AI agents, crypto payment infrastructure, and cross-border payout systems with Rust, Go, and TypeScript. Based in London, UK.

Currently open to new opportunities in fintech, crypto payments, and AI agent engineering.

Portfolio | LinkedIn | GitHub | Email

Mastercard Settles Cards on Solana, 24/7

Tom Wang — Mon, 08 Jun 2026 15:37:04 +0000

On 3 June 2026, Mastercard quietly rewired one of the oldest assumptions in payments. The company announced it will settle card transactions on-chain in regulated stablecoins — intraday, at weekends, on bank holidays, around the clock — with Solana as the lead settlement rail. For most consumers this changes nothing visible. For anyone who builds payment infrastructure, it is one of the most consequential back-office shifts of the year. As a fintech developer and payment developer who spends his days inside settlement and reconciliation systems, I think this is the moment on-chain settlement stopped being a pilot and started becoming plumbing.

What Mastercard Actually Changed

Card networks have always run on a split-brain model. Authorisation happens in milliseconds — your card is approved at the terminal almost instantly. Settlement, the part where money actually moves between the acquiring bank and the issuing bank, happens in batches during banking hours, typically T+1 or T+2. That mismatch between instant authorisation and delayed, business-hours settlement is a relic of correspondent banking, and it is exactly what creates float, reconciliation headaches, and weekend liquidity gaps.

Mastercard's announcement attacks that gap directly. Raj Dhamodharan, the company's EVP of blockchain and digital assets, framed it bluntly: "The next phase of stablecoin adoption is about real-world utility, especially in settlement." The network will let participants settle in a basket of regulated stablecoins — Circle's USDC, Paxos-issued PYUSD, USDG and USDP, Ripple's RLUSD, and SoFi's SoFiUSD — across eight blockchains including Arbitrum, Base, Ethereum, Polygon, Solana, XRPL, Canton and Tempo. Solana is the launch rail for the deepest integration.

Early adopters named for the rollout include Cross River, Lead Bank, CBW Bank, ARQ (formerly DolarApp) and Nuvei, starting in the US and Latin America and expanding through 2026. This is an early-phase rollout, not a flip-the-switch GA event — USDC settlement is already live in select markets, and the rest is staged. But the direction of travel is unambiguous: a network spanning billions of cards is moving its settlement layer onto rails that never close.

Why Solana, and Why Developers Should Care

The most interesting detail for engineers is how this is wired. Mastercard's settlement does not run through a bespoke, hand-rolled chain integration. It flows through the Solana Developer Platform (SDP), the API-driven institutional toolbox the Solana Foundation launched on 24 March 2026 with Mastercard, Worldpay and Western Union among the anchor partners.

SDP matters because it abstracts the chain away behind three modules: tokenised real-world asset issuance, fiat-plus-stablecoin payments, and a forthcoming trading and on-chain FX module. Under the hood it unifies more than twenty infrastructure providers — node access via Alchemy and QuickNode, custody and wallets through Fireblocks and Coinbase, and compliance screening from Chainalysis and Elliptic. Worldpay already uses it for merchant settlement; Western Union for cross-border. In other words, a payment engineer integrating against this stack is not writing raw Solana programs from scratch — they are calling an API surface that handles issuance, custody, and compliance hooks for them.

Read the full article on tomcn.uk →

About the Author

I'm Tom Wang, an AI Developer & Fintech Developer — building AI agents, crypto payment infrastructure, and cross-border payout systems with Rust, Go, and TypeScript. Based in London, UK.

Currently open to new opportunities in fintech, crypto payments, and AI agent engineering.

Portfolio | LinkedIn | GitHub | Email

UK Open Banking Launches Its Card Challenger

Tom Wang — Sun, 07 Jun 2026 10:33:38 +0000

For eight years, UK open banking has been a brilliant set of rails without a timetable. The plumbing worked — millions of account-to-account payments cleared every month — but there was no shared commercial framework to make recurring, card-free payments a mainstream default. On 2 June 2026, at Money20/20 Europe, that changed. The UK Payments Initiative (UKPI) went live with a finalised rulebook, a commercial model and operational standards for flexible, automated, recurring account-to-account payments. As a fintech developer and payment developer who has spent years wiring up Open Banking APIs, I think this is the most consequential structural upgrade to UK payments since Faster Payments launched.

This is not another pilot. UKPI Ltd is backed by an unusually broad coalition of founding shareholders — Barclays, HSBC, Lloyds Banking Group, NatWest, Nationwide, Santander, Monzo, Revolut and Starling on the bank side, with Acquired, GoCardless, Plaid, TrueLayer and Yapily among the fintech founding members. When the high-street banks and the open banking fintechs sit at the same table and agree a rulebook, the thing that has been missing for years finally arrives: certainty.

What the UKPI scheme actually standardises

The headline capability is commercial variable recurring payments (cVRP) — recurring account-to-account payments where the consumer, not the merchant, sets the rules. Under the scheme a payer can define how long a permission lasts, the maximum that can be taken, and exactly who receives the money, all without sharing card details or setting up a traditional direct debit. The permission lives in the bank, is visible in the banking app, and can be revoked in one tap.

For a payment developer, the value of UKPI is less the technology — VRP has existed as an API pattern for a while — and more the scheme layer sitting on top of it:

A shared rulebook that defines liability, dispute handling and refund obligations across every participant, so you build to one specification rather than negotiating bilaterally with each bank.
A commercial model that finally answers "who pays whom" — the question that quietly killed countless open banking business cases.
Operational standards for availability, performance and consumer protection, moving cVRP out of bespoke bank-by-bank integrations and toward predictable, scheme-grade reliability.

The FCA, which published a supporting statement the same day, called it "a major step forward for open banking and commercial variable recurring payments" and said it expects the launch to act "as a catalyst for other initiatives to emerge." Critically, the regulator confirmed it will consult on a long-term regulatory framework by the end of 2026 and supports establishing an independent standards-setting body. That sequencing — industry ships the rulebook, regulator codifies it afterwards — is how durable payment infrastructure usually gets built.

Read the full article on tomcn.uk →

About the Author

I'm Tom Wang, an AI Developer & Fintech Developer — building AI agents, crypto payment infrastructure, and cross-border payout systems with Rust, Go, and TypeScript. Based in London, UK.

Currently open to new opportunities in fintech, crypto payments, and AI agent engineering.

Portfolio | LinkedIn | GitHub | Email