Today is Cyber Monday. Here is how money moves when you click the Buy button on Amazon or any of your favorite shopping websites. 1. When a user clicks the “Buy” button, a payment event is generated and sent to the payment service. 2. The payment service stores the payment event in the database.
I have trouble wrapping my head around why we need ledger and wallet. In my mind these are all derived information that shouldn't be part of the payment flow. At best these just need to be updated asynchronously to be used for e.g. reconciliation as mentioned. Can you explain why you design them to be part of the payment flow?
Hi Alex. I’m reading the Volume 2 of your book. If a payment event is broken down to n payment orders and the idempotency key is in the payment order, wouldn’t the buyer have to complete multiple “payment” n times?
This is REALLY superficial. Any good interviewer would dig deeper into the DB, whether the ones shown are the same or different, SQL/NOSQL, txn failures modes, database schema etc. This diagram may be ok for an intern applying for a company no one has heard of, but beyond that, it's insufficient.
the payment service is the api to connect between mobile and Backend. ? Payment executer is the use case or BE service ? If we want to create the payment sdk, what kind of certification process needed ?
I have trouble wrapping my head around why we need ledger and wallet. In my mind these are all derived information that shouldn't be part of the payment flow. At best these just need to be updated asynchronously to be used for e.g. reconciliation as mentioned. Can you explain why you design them to be part of the payment flow?
How will the system remain in consistent state if there's a failure in wallet service or ledger service?
Should there be a synchronous transaction among all the services involved? If yes, how would it be implemented.
You might also wanna consider gift cards and order cancellations in this aspect? What are your thoughts?
Hi Alex. I’m reading the Volume 2 of your book. If a payment event is broken down to n payment orders and the idempotency key is in the payment order, wouldn’t the buyer have to complete multiple “payment” n times?
This is REALLY superficial. Any good interviewer would dig deeper into the DB, whether the ones shown are the same or different, SQL/NOSQL, txn failures modes, database schema etc. This diagram may be ok for an intern applying for a company no one has heard of, but beyond that, it's insufficient.
Which is the payment executor in this scenario ?
How and when would Amazon/seller get the money for the sale? Can you elaborate on the settlement process a bit please?
Could you please shed some light on BNPL SD Alex?
very useful design flow：thanks
reconciliation：对账
Ledger：账本
settlement file：结算文件
the payment service is the api to connect between mobile and Backend. ? Payment executer is the use case or BE service ? If we want to create the payment sdk, what kind of certification process needed ?