One payment.
One clear story.

Connect my café campaign summary and supporter dashboard to one consistent database source. Inspect the existing payment confirmation and aggregate queries before changing them.

The campaign summary needs a goal, provider-confirmed TEST payment total, unique test-supporter count and accessible progress bar. Derive totals from eligible confirmed records on the server. Do not count pending, failed, cancelled or expired checkouts. Repeated provider events and retries must not increase the total twice. Count a returning supporter once rather than as a new person for every contribution. If my current app uses a different documented definition, explain it before changing the query.

Keep personal account history private and separate from the public aggregate. Public responses must not expose emails, payment identifiers or private notes. If the backend hosts several apps, scope the aggregate to the intended application and campaign.

Fetch current totals when the campaign is opened and provide a real refresh path after payment confirmation. Show loading or unavailable states rather than fake activity. Do not add a fabricated scrolling donor ticker or imply WebSocket/push support unless it is actually implemented. Format rupee amounts consistently from integer paise and cap the visual progress bar at 100% without hiding the actual total.

For the verification, start with an isolated zero-state test fixture, confirm a ₹500 test payment, and check that the total is ₹500 and supporter count is one. Repeat the same event and confirm there is no second credit. Test a second contribution by the same user and a contribution by another user against the stated supporter definition. Check that both the dashboard and campaign agree after a reload. Do not reset or invent production activity to make the test look convincing.

Finish by showing desktop and mobile-friendly layouts and a concise record of actual tests. Explain any remaining dependencies honestly.