DA10: Capstone: three automations for Sharma Textiles

Lesson 2 of 5 · reading 15–25 minutes; practice and project time is on the module page

Project 1: the payment workflow

🎯You'll be able to

Build the payment workflow end to end and prove it with all ten acceptance tests, including duplicates and recovery.

🏠The everyday picture

At a shop counter, the cashier takes payment, writes the bill, updates the register and tells the packer. The payment workflow does the same chain, automatically and in seconds.

📘What it really is

The full flow, joining earlier modules:
Webhook (production URL) receives payment.captured, keeps the raw body, and checks the signature (DA7);
store the event in the payment_events table, then reply 200 (DA6), so nothing is lost if a later step fails;
claim the event, so only one run works on it even when duplicates arrive at the same moment (DA6);
confirm the payment through the API: status and amount in paise (DA7);
map to the invoice and CRM fields with units and IST dates (DA4);
create the invoice with the payment ID as the idempotency key and move the CRM deal (DA8);
mark the event done only after every step succeeds; on a lasting error mark it failed and alert an owner once (DA6);
recover: a scheduled workflow retries events left received or failed (DA6).
Acceptance tests: the ten in the starter kit's tests/payment.js, run against the practice simulator:
a normal payment; an advance (part payment);
the same event three times in a row, and five times at the same moment;
a wrong signature; an event the gateway API doesn't confirm;
accounts busy (503) then recovering; an expired accounts credential (401);
the CRM failing after you replied 200, then your recovery finishing the job;
a whole-run check that every invoice matches a captured payment.

📝A worked example

A learner's test results:

Test	Expected	Result (illustrative)
1. Normal payment ₹2,400	1 invoice, deal won, IST time right	✓
2. Advance ₹70,800 of ₹2,36,000	Invoice part-paid; deal part-paid	✓
3. Same event × 3 in a row	1 invoice	✓
4. Same event × 5 at once	1 invoice	✗ first: 2 invoices
5. Fake signature	401; nothing created	✓
6. Gateway says failed	No invoice	✓
7. Accounts 503 then OK	Retried; 1 invoice	✓
8. Accounts 401	1 to 3 alerts naming the order and an owner	✗ first: alert had no order ID
9. CRM down after the reply	Alert, then recovery completes it once	✓
10. Whole run	Every invoice matches a captured payment	✓ after fixes

Test 4 failed because two parallel runs both read "not processed yet" before either wrote. Claiming the event with a database update that only one run can win fixed it. Test 8 showed the alert template read the order ID from the wrong node. After both fixes, all ten tests were rerun together and passed.

🌍Where it's used

Online shops and wholesale businesses taking payments by link, UPI or card.
Service businesses taking deposits.
Subscriptions, with the same pattern for renewals.

📝Case scenario

In the demo, the reviewer asks what happens if the CRM is down when a payment arrives. The learner shows that the invoice step is idempotent, the CRM step retries with backoff, and if it still fails, the alert reaches Priya and the run can be retried without a second invoice. Because "processed" is recorded last, the retry completes the CRM update.

🖱️Try it

Build the payment workflow against the practice simulator and run the ten acceptance tests. Record each result, and rerun all of them after any fix.

⚠️Common mistakes

Testing duplicates only one after another. Sign: test 3 passes but test 4 fails. Fix: claim the event in the database so only one parallel run wins.
Replying 200 before storing the event. Sign: test 9 can't recover because the event is gone. Fix: store first, then reply.

🛠️For your project

This is Project 1. Run node tests/payment.js from the starter kit and save the output as your test evidence.

✅Quick check

Why record the payment as processed only after every step succeeds?

Show the answer

So a retried run can finish the steps that failed, while the duplicate check still stops a full second run.

Which two checks stop a fake payment event from creating an invoice?

Show the answer

The signature check, and confirming the payment through the gateway's API.