In general, reconciliation is done asynchronously. You send a payment out. The processor some number of days later sends out a file containing information about

In general, reconciliation is done asynchronously. You send a payment out. The processor some number of days later sends out a file containing information about that payment. You validate that the payment the processor recognized is the same as the one you sent out. That's a high level summary. Also regarding dual write consistency problems: they mention Google cloud. If they're using NoSQL such as Data store/firestore, they have distributed transactions. Another possibility is they must trust their payment clients to use idempotency keys correctly. If you get two requests with the same idempotency keys, then the requests are considered to be the same and therefore it wouldn't matter which one is processed first. If they're different requests with the same idempotency keys, they may have some validations. I believe DynamoDB also has conditional writes that can essentially be "if entity X does not exist: write entity X". Then there is a race condition for different requests with identical idempotency keys, but if that does happen, it'd result in an error and someone would need to look into it and figure out why that was allowed to happen.