Donation Flow — Payment Intents + Stripe Elements POC

# Donation Flow — Payment Intents + Stripe Elements POC

Purpose: Proposal for discussion with tech lead. Documents a new donation
payment flow using Stripe Payment Intents + Stripe Elements, replacing the
Stripe-hosted Checkout Session page with a custom payment UI on our frontend.

>

Status: POC — not yet implemented.
Date: July 2026

Table of Contents

1. [Executive Summary](#1-executive-summary)

2. [Current Flow (As-Is)](#2-current-flow-as-is)

3. [Proposed Flow (To-Be) — End-to-End](#3-proposed-flow-to-be--end-to-end)

4. [API Endpoints](#4-api-endpoints)

5. [Payment Methods](#5-payment-methods)

6. [Single Endpoint Routing Logic](#6-single-endpoint-routing-logic)

7. [Guest Checkout Flow](#7-guest-checkout-flow)

8. [Webhook Fulfillment](#8-webhook-fulfillment)

9. [Security Considerations](#9-security-considerations)

10. [Frontend Integration (High-Level)](#10-frontend-integration-high-level)

11. [What Stays Unchanged](#11-what-stays-unchanged)

12. [Database Changes](#12-database-changes)

13. [Architecture Diagram](#13-architecture-diagram)

14. [Risks & Mitigations](#14-risks--mitigations)

15. [Decision Points for Lead](#15-decision-points-for-lead)

1. Executive Summary

What we're proposing

Shift the donation payment experience from Stripe Checkout Sessions (a

Stripe-hosted payment page that the donor redirects to) to **Stripe Payment

Intents + Stripe Elements** (a custom payment form embedded in our own donation

page).

Why

1. Payment method selection on our page — the donation page needs to show

available payment methods (card, PayNow, GrabPay, etc.) as part of the UI,

not on a separate Stripe-hosted page. This gives us control over the layout,

branding, and user experience.

2. Guest checkout — donors who don't have a 3Degrees account should be able

to donate without signing up. Currently all donation endpoints require JWT

auth.

3. Better UX — no redirect to Stripe's domain. The entire donation flow

stays on our page. The donor enters card details in an embedded Stripe

Elements iframe (PCI-compliant) and sees success/failure inline.

Scope

• Regions: SG and AU (Stripe) only. Indonesia stays on Midtrans Snap — no

changes to the Midtrans flow.

• Coexistence: new endpoints are added alongside the existing ones. The

current POST /donate and POST /donate-direct (Checkout Session flow)

remain untouched and functional. This is zero-risk to the existing flow.

• Webhook: no changes needed. The existing payment_intent.succeeded

webhook handler already fulfills donations by looking up the PI ID.

Single endpoint

Instead of 4 separate endpoints (auth/guest × campaign/direct), we propose

one endpoint (POST /donor/donate-payment-intent) that handles all cases

internally. This reduces maintenance burden and keeps the API surface clean.

2. Current Flow (As-Is)

Full detail: see docs/donation-flow.md.

Donor (authenticated)
  │
  │  POST /donor/donate
  │  { campaign_uid, donation_amount, chariot_tip, platform_charge, ... }
  │
  ▼
donor-api: DonateUseCase
  ├── Validate amounts, resolve campaign + NGO
  ├── Check tax deductibility
  ├── Insert donation row (status: pending)
  ├── Create Stripe Checkout Session (mode: 'payment')
  │   → Stripe returns a hosted checkout URL
  ├── Update donation row with session + PI ID
  └── Return { payment_url: "https://checkout.stripe.com/...", donation_uid }
  │
  ▼
Frontend redirects donor to payment_url (Stripe-hosted page)
  │
  │  Donor selects payment method + enters card on Stripe's page
  │  Stripe processes payment
  │
  ▼
Stripe fires webhook → webhook app fulfills donation
  ├── Update donation to 'payment_intent.succeeded'
  ├── Send email, Pusher events, notifications
  └── Invalidate cache

Limitations:

• Donor must be authenticated (JWT) — no guest checkout.
• Payment method selection happens on Stripe's page, not ours.
• Full-page redirect to checkout.stripe.com — breaks the in-app experience.
• No control over the payment form layout or branding.

3. Proposed Flow (To-Be) — End-to-End

This is the core of the new flow. The entire donor journey from opening the donation page to donation completion.

3.1 The Donor Journey

3.2 Backend Perspective — Step-by-Step

When POST /donor/donate-payment-intent arrives, the backend processes these 9 steps before returning a response:

3.3 After the Backend Responds — Swimlane View

Note on Midtrans (Indonesia): When the NGO is in Indonesia, the flow differs at step 9 — the backend creates a Midtrans Snap transaction and returns a payment_url instead of client_secret. The donor is redirected to the Midtrans-hosted Snap page (same as today’s flow). Midtrans sends an async notification to POST /midtrans/notification which the existing webhook handler processes.

4. API Endpoints

4.1 GET /donor/payment-methods-elements

Returns the list of available Stripe payment methods for a given region/currency.

The frontend uses this to render a custom payment method selector before

mounting the Payment Element.

Auth: @Public() (no JWT required — needed before guest donors donate)

Query params:

Request example:

GET /donor/payment-methods-elements?country_code=SG

Response (200):

{
  "data": [
    {
      "type": "card",
      "label": "Credit / Debit Card",
      "icon": "card",
      "description": "Visa, Mastercard, Amex"
    },
    {
      "type": "paynow",
      "label": "PayNow",
      "icon": "paynow",
      "description": "Scan QR code to pay"
    },
    {
      "type": "grabpay",
      "label": "GrabPay",
      "icon": "grabpay",
      "description": "Pay with GrabPay wallet"
    },
    {
      "type": "alipay",
      "label": "Alipay",
      "icon": "alipay",
      "description": "Pay with Alipay"
    },
    {
      "type": "wechat_pay",
      "label": "WeChat Pay",
      "icon": "wechat_pay",
      "description": "Pay with WeChat Pay"
    }
  ],
  "message": "Payment methods retrieved successfully"
}

AU response:

{
  "data": [
    {
      "type": "card",
      "label": "Credit / Debit Card",
      "icon": "card",
      "description": "Visa, Mastercard, Amex"
    },
    {
      "type": "au_becs_debit",
      "label": "BECS Direct Debit",
      "icon": "au_becs_debit",
      "description": "Australian bank account"
    },
    {
      "type": "afterpay_clearpay",
      "label": "Afterpay / Clearpay",
      "icon": "afterpay_clearpay",
      "description": "Buy now, pay later (4 installments)"
    },
    {
      "type": "zip",
      "label": "Zip",
      "icon": "zip",
      "description": "Buy now, pay later"
    },
    {
      "type": "paypal",
      "label": "PayPal",
      "icon": "paypal",
      "description": "Pay with PayPal account"
    }
  ],
  "message": "Payment methods retrieved successfully"
}

Note: The Payment Element will still only display methods that are
actually enabled in the Stripe Dashboard. This endpoint returns our curated
list — the frontend uses it for the selector UI, but the Payment Element is
the source of truth for what's actually rendered.

4.2 POST /donor/donate-payment-intent

Creates a donation and returns a PaymentIntent client_secret (for Stripe

regions) or a payment_url (for Midtrans/Indonesia).

Auth: OptionalAuth — accepts JWT if present, works without it for guests.

Request body:

• campaign_id number — *(one of campaign/ngo)* Campaign ID to donate to
• campaign_uid string — *(one of campaign/ngo)* Campaign UID to donate to
• ngo_id number — *(one of campaign/ngo)* NGO ID for direct donation
• ngo_uid string — *(one of campaign/ngo)* NGO UID for direct donation
• donation_amount number — *(required)* Amount in cents (e.g. 50000 = S$500)
• chariot_tip number — *(optional, default 0)* Tip in cents
• platform_charge number — *(required)* Platform fee in cents
• country_code string — *(required)* SG \| AU \| ID — donor's country
• is_anonymous boolean — *(required)* Whether donation is anonymous
• tax_deductible_id string — *(optional)* Donor's government tax ID
• message_from_donor string — *(optional)* Message to NGO
• platform_source string — *(optional, default 'web')* web \| ios \| android
• email string — *(optional, guests)* Guest donor's email. If not provided,

email is extracted from Stripe's webhook payload (billing_details.email) at

fulfillment time. Non-card methods (PayNow, GrabPay) may not provide an email —

in that case dud_guest_email stays null and no receipt email is sent.

• name string — *(optional, guests)* Guest donor's name. Used for display

purposes only if provided.

• payment_method_type string — *(optional)* Restrict the PaymentIntent to

a specific method (e.g. grabpay, card, paynow). See

[4.3 Payment Method Restriction](#43-payment-method-restriction).

Routing rules:

• If campaign_id or campaign_uid is provided → campaign donation.
• If only ngo_id or ngo_uid is provided → direct NGO donation.
• If no JWT → guest flow (email/name are optional, not required).
• If payment_method_type provided → restrict PI to that method only.
• If payment_method_type omitted → use automatic_payment_methods (show all).

Request example — authenticated, campaign donation:

{
  "campaign_uid": "abc123",
  "donation_amount": 50000,
  "chariot_tip": 5000,
  "platform_charge": 2500,
  "country_code": "SG",
  "is_anonymous": false,
  "tax_deductible_id": "S1234567A",
  "message_from_donor": "Keep up the great work!",
  "platform_source": "web"
}

Request example — guest, direct NGO donation:

{
  "ngo_uid": "xyz789",
  "donation_amount": 25000,
  "chariot_tip": 0,
  "platform_charge": 1250,
  "country_code": "AU",
  "is_anonymous": true,
  "email": "guest@example.com",
  "name": "John Doe",
  "payment_method_type": "grabpay",
  "platform_source": "web"
}

Response (200) — Stripe (SG/AU):

{
  "data": {
    "client_secret": "pi_3PqA..._secret_XyZ456...",
    "donation_uid": "x7k9m2",
    "payment_intent_id": "pi_3PqA..."
  },
  "message": "Payment intent created successfully"
}

Response (200) — Midtrans (ID):

{
  "data": {
    "payment_url": "https://app.sandbox.midtrans.com/snap/v3/redirection/abc123",
    "donation_uid": "x7k9m2"
  },
  "message": "Payment intent created successfully"
}

Response (400) — invalid payment method type:

{
  "statusCode": 400,
  "message": "Invalid payment method type for this currency",
  "error": "Bad Request"
}

4.3 Payment Method Restriction

When the donor selects a specific payment method on the donation page (e.g.

"GrabPay"), the frontend sends payment_method_type in the request body. The

backend restricts the PaymentIntent to that method only — the Payment Element

will render only the selected method, not all Dashboard-enabled methods.

How it works:

Backend logic:

if (paymentMethodType) {
  // Restrict to the selected method
  paymentIntent = await stripe.paymentIntents.create({
    amount,
    currency,
    payment_method_types: [paymentMethodType],
    metadata: { donation_uid, donation_id, ngo_id },
    ...(customerId ? { customer: customerId } : {}),
    ...(email ? { receipt_email: email } : {}),
  });
} else {
  // Show all methods (default)
  paymentIntent = await stripe.paymentIntents.create({
    amount,
    currency,
    automatic_payment_methods: { enabled: true },
    metadata: { donation_uid, donation_id, ngo_id },
    ...(customerId ? { customer: customerId } : {}),
    ...(email ? { receipt_email: email } : {}),
  });
}

Trade-offs:

Recommendation: Use the hybrid approach — payment_method_type is optional.

If the frontend sends it → restrict. If not → show all. This lets the frontend

decide per page whether to restrict or show all methods.

5. Payment Methods

Curated lists per region

The GET /donor/payment-methods-elements endpoint returns a curated list based

on the donor's region. These are the payment methods we want to surface in our

custom selector UI.

Singapore (SG):

Australia (AU):

How it works with the Payment Element

1. Frontend fetches the curated list → renders custom selector buttons.

2. Donor selects a method (e.g. "PayNow").

3. Frontend calls POST /donate-payment-intent → gets client_secret.

4. Frontend mounts the Stripe Payment Element with client_secret.

5. The Payment Element renders the appropriate input fields for the selected

method (or shows the method selection itself if we don't pre-select).

6. The Payment Element only shows methods enabled in the Stripe Dashboard

for the given currency — our curated list is a UI hint, not a guarantee.

Important: To use these methods, they must also be enabled in the Stripe
Dashboard under Settings → Payment methods. If a method is in our curated
list but not enabled in the Dashboard, the Payment Element won't render it.
The curated list and Dashboard settings must be kept in sync.

6. Single Endpoint Routing Logic

One endpoint, four cases. The use case branches internally based on what's provided in the request and whether a JWT is present.

Decision Matrix

The single endpoint handles all four combinations — campaign/direct × authenticated/guest — by branching on two axes:

Provider Routing

The NGO's base country determines which payment provider handles the transaction:

Internal Routing Logic

The use case's execute() method processes these 11 steps:

Why a Single Endpoint

7. Guest Checkout Flow

What a guest is

A guest is a donor who does not have a 3Degrees account and is not logged in.

They arrive at a donation page (e.g. via a shared campaign link) and want to

donate without signing up.

What the guest provides

No tax_deductible_id for guests — tax deduction requires a user account with a

verified government ID. Guest donations are always isValidForTaxDeduction: false.

No Stripe Customer is created for guests. The PaymentIntent is created without a

customer field. The email (if provided) is set as receipt_email on the PI.

Backend Handling of a Guest Donation

Guest Flow End-to-End

{ campaign_uid, donation_amount,
  country_code, ...
  payment_method_type: 'grabpay',
  email: 'guest@...' (optional) }

{ client_secret, donation_uid, payment_intent_id }

Anonymous guest donations

If a guest sets is_anonymous: true:

• The donation row has dud_is_anonymous = true.
• The webhook handler checks !donation.donation.isAnonymous before notifying

the NGO and followers — so anonymous guests don't trigger notifications.

• The receipt email is sent to dud_guest_email if present. If the guest

didn't provide an email and the payment method didn't capture one (e.g.

PayNow, GrabPay), no receipt email is sent.

• The NGO sees the donation in their feed but the donor shows as "Anonymous".

8. Webhook Fulfillment

Why no webhook changes are needed

The existing webhook handler at

apps/webhook/src/modules/payment/application/usecases/handle-stripe-donation-webhook.usecase.ts

already handles payment_intent.succeeded by:

1. Finding the donation via repo.getDonationByPaymentIntent(pi.id).

2. Looking up dud_stripe_payment_intent_id (which we set at PI creation time).

3. Fulfilling: update status, send email, trigger Pusher, notify NGO.

In the current Checkout Session flow, the PI ID is set in two phases:

• routeStripe() sets it from session.payment_intent at creation time.
• The checkout.session.completed webhook event links it as a fallback.

In the new Payment Intent flow, the PI ID is set **directly at creation

time** — we create the PI ourselves and store its ID immediately. This means:

• The webhook handler finds the donation on the first payment_intent.succeeded

event without any linking step.

• The checkout.session.completed event is irrelevant (we don't use Checkout

Sessions in the new flow).

• No new webhook handler is needed.

Guest email extraction (new — added to existing handler)

For guest donations where dud_guest_email is null at insertion time (donor

didn't provide an email in the request), the webhook handler needs a small

addition to extract the email from Stripe's charge data:

On payment_intent.succeeded:
  ...existing steps (find donation, retrieve expanded PI)...

  IF donation.dud_u_id is null (guest) AND donation.dud_guest_email is null:
    charge = expandedPi.charges.data[0]
    IF charge.billing_details.email:
      repo.updateDonationGuestEmail(donation.dudId, charge.billing_details.email)
      → dud_guest_email is now populated

  Send receipt email:
    IF donation.dud_guest_email is present:
      sendPostDonationEmail(donation, email = dud_guest_email)
    ELSE:
      skip receipt email (non-card methods like PayNow/GrabPay may not have email)

This is the only new logic added to the webhook handler. The rest of the

fulfillment (status update, Pusher, NGO notification, cache invalidation) is

unchanged.

Webhook events that matter

What about the donation_reference_id metadata fallback?

The existing handler has a fallback path: if the donation isn't found by PI ID,

it looks up paymentIntent.metadata.donation_reference_id and links the PI ID

to the donation by UID. In the new flow, this fallback is still useful as a

safety net — we include donation_reference_id in the PI metadata, so if

anything goes wrong with the initial PI ID storage, the webhook can still

repair the link.

Existing delByPattern('*') issue

The current webhook handler calls redisService.delByPattern('*') which wipes

the entire Redis DB. This affects both the old and new flow. If we're touching

the donation flow, we should fix this as part of the work — replace with scoped

patterns:

// Instead of:
await redisService.delByPattern('*');

// Use:
await this.redisService.delByPattern('donation:*');
await this.redisService.delByPattern('leaderboard:*');
await this.redisService.delByPattern('ngo:donations:*');
await this.redisService.delByPattern('campaign:donations:*');

This is a known issue (documented in docs/donation-flow.md section 15.6) and

is called out in AGENTS.md. The new flow inherits this issue since it uses the

same webhook handler.

9. Security Considerations

Is client_secret safe to send to the frontend?

Yes. Stripe explicitly designs the client_secret to be client-facing. It

is not a server-side secret like the API key (sk_***).

Key point: Even if an attacker intercepts the client_secret, they cannot:

• Change the amount (set server-side at PI creation).
• Create new PaymentIntents.
• Access other donations.
• Refund charges.
• Access the Stripe account.

The client_secret can only confirm that one specific payment for **that

exact amount** — which is what the donor wants to do anyway.

Real protections we need

PCI compliance

Stripe Elements renders card inputs in an iframe hosted on Stripe's domain.

Card data (PAN, expiry, CVC) goes directly from the donor's browser to Stripe's

servers — it never touches our backend, our frontend JavaScript, or our logs.

This means our PCI scope is SAQ A (the lowest burden) — same as the current

Checkout Session flow. Switching to Elements does not increase PCI scope.

Guest endpoint abuse

The guest endpoint is @Public() — no JWT required. Risks:

10. Frontend Integration (High-Level)

Dependencies

# React
npm install @stripe/react-stripe-js @stripe/stripe-js

# Or vanilla JS
npm install @stripe/stripe-js

Flow (React example)

import { loadStripe } from '@stripe/stripe-js';
import { Elements, PaymentElement } from '@stripe/react-stripe-js';

const stripePromise = loadStripe(STRIPE_PUBLISHABLE_KEY);

function DonationPage() {
  const [clientSecret, setClientSecret] = useState(null);
  const [donationUid, setDonationUid] = useState(null);

  // 1. Donor fills in amount, clicks "Donate"
  async function handleDonate() {
    const res = await fetch('/donor/donate-payment-intent', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        ...(jwt ? { Authorization: `Bearer ${jwt}` } : {}),
      },
      body: JSON.stringify({
        campaign_uid: 'abc123',
        donation_amount: 50000,
        chariot_tip: 5000,
        platform_charge: 2500,
        country_code: 'SG',
        is_anonymous: false,
        // Guests also send: email, name
      }),
    });
    const { data } = await res.json();
    setClientSecret(data.client_secret);
    setDonationUid(data.donation_uid);
  }

  // 2. Once we have client_secret, render the Payment Element
  if (clientSecret) {
    const options = {
      clientSecret,
      appearance: { theme: 'stripe' },
    };
    return (
      <Elements stripe={stripePromise} options={options}>
        <CheckoutForm donationUid={donationUid} />
      </Elements>
    );
  }

  return <DonationForm onSubmit={handleDonate} />;
}

function CheckoutForm({ donationUid }) {
  const stripe = useStripe();
  const elements = useElements();

  async function handleSubmit(e) {
    e.preventDefault();

    // 3. Confirm the payment
    const { error } = await stripe.confirmPayment({
      elements,
      redirect: 'if_required',
    });

    if (error) {
      // Show error (card declined, validation error, etc.)
      console.error(error.message);
    } else {
      // Payment succeeded — webhook will fulfill async
      // Poll GET /donor/donation?donation_uid=... to confirm
      window.location.href = `/donation/success?uid=${donationUid}`;
    }
  }

  return (
    <form onSubmit={handleSubmit}>
      <PaymentElement />
      <button type="submit" disabled={!stripe}>Pay</button>
    </form>
  );
}

3DS / SCA handling

When stripe.confirmPayment() is called:

• If the card requires 3D Secure, Stripe.js automatically opens a 3DS modal

(or redirects to the bank's authentication page).

• With redirect: 'if_required', Stripe only redirects if the payment method

requires a full redirect (e.g. some bank redirects). Card 3DS is handled

inline.

• After 3DS completes, the promise resolves with success or error.
• No backend involvement is needed for 3DS — it's entirely client-side.

Payment method pre-selection

If the frontend has a custom payment method selector (from

GET /payment-methods-elements), it can pass the selected method to the

Payment Element:

const paymentElement = elements.create('payment', {
  defaultValues: {
    // Pre-select the donor's chosen method
  },
});

Or use the Payment Element's built-in method selector (simpler, less custom UI).

11. What Stays Unchanged

Migration path (if we later want to deprecate the old flow)

1. Ship the new endpoint alongside the old ones.

2. Frontend migrates to the new endpoint (per page or feature flag).

3. Monitor for issues — both flows share the same webhook, so fulfillment is

identical.

4. Once the frontend fully migrates, deprecate POST /donate and

POST /donate-direct (return 410 Gone or redirect).

5. Remove old endpoint code + createCheckoutSession if no longer used.

No rush — the old flow can coexist indefinitely.

12. Database Changes

New column

ALTER TABLE donor_user_donates
  ADD COLUMN dud_guest_email VARCHAR(255) NULL AFTER dud_u_id;

Why only one column?

• dud_u_id is already nullable (int('dud_u_id') with no .notNull()) —

guests set it to NULL.

• dud_is_anonymous already exists — guests can be anonymous or not.
• dud_country_code already exists — guest's country is stored.
• Guest's name is not stored in our DB — it's only used for display if provided

in the request. The email is sufficient for receipts.

• dud_stripe_payment_intent_id already exists — stores the PI ID.
• dud_stripe_status already exists — tracks payment status.

Note: dud_guest_email may be null at insertion time for guests who don't
provide an email in the request. The webhook handler populates it from
charges.data[0].billing_details.email when the payment method captures email
(credit cards do; PayNow/GrabPay typically don't). If the payment method
doesn't provide an email, the column stays null and no receipt email is sent.

Migration

• Drizzle migration (forward-only, per project conventions).
• Generated via pnpm db:generate.
• Review the SQL before applying.
• No data backfill needed — the column is nullable, existing rows get NULL.

13. Architecture Diagram

14. Risks & Mitigations

15. Decision Points for Lead

These are the open questions that need a decision before implementation:

15.1 Coexistence vs full replacement

Recommendation: Coexist. Ship the new endpoint alongside the old ones. Let

the frontend migrate at its own pace. Deprecate the old endpoints only after

full migration.

Alternative: Full replacement — modify the existing POST /donate and

POST /donate-direct to use the PI flow. Riskier (breaks current frontend

immediately) but cleaner long-term.

15.2 Guest Stripe Customer strategy

Recommendation: Don't create a Stripe Customer for guests. Create the

PaymentIntent without a customer field. Set receipt_email if the guest

provides an email. Extract email from the webhook's billing_details.email

for guests who don't provide one upfront.

Rationale: Simpler, no orphan Customer objects on Stripe, no dual-region

complexity. The trade-off is no saved cards / portal / subscriptions for

guests — acceptable for a POC. If the guest later signs up, the PaymentIntent's

customer can be retroactively associated.

Alternative A: Create a lightweight user record (with a is_guest flag)

+ dual-region Stripe Customers. Enables "claim your account" later. More work,

more schema changes.

Alternative B: Create a Stripe Customer without email (just metadata:

{ guest: 'true' }). Attach it to the PaymentIntent. Can update the customer's

email later from the webhook if billing_details.email is present. Middle

ground — customer association but no orphan email-less customers.

15.3 Curated payment method list vs automatic

Recommendation: Curated list via GET /payment-methods-elements (per

region). Frontend renders a custom selector. Payment Element still filters by

Dashboard settings.

Alternative: No curated list — just use automatic_payment_methods: { enabled: true }

on the PI and let the Payment Element auto-display all relevant methods.

Simpler backend, less custom UI, but less control over the payment method

selector layout.

15.4 Rate limiting

Recommendation: Add rate limiting to the guest endpoint now. Suggest 10

requests/minute per IP for guests, 30/minute for authenticated donors. Use

@nestjs/throttler or Redis-based limiter.

Alternative: Defer rate limiting — ship first, add later. Risk: guest

endpoint is public and could be abused.

15.5 delByPattern('*') fix

Recommendation: Fix as part of this work. Replace with scoped cache

patterns in all three webhook handlers (SG, AU, Midtrans). This is a P0 issue

that affects all donations — not just the new flow.

Alternative: Fix separately in a dedicated PR. Keeps this PR smaller but

leaves the risk in place longer.

15.6 Midtrans in the same endpoint?

Recommendation: Yes — POST /donate-payment-intent auto-routes to Midtrans

for ID NGOs and returns payment_url instead of client_secret. The frontend

checks which field is present and handles accordingly (redirect for Midtrans,

Elements for Stripe).

Alternative: Exclude Midtrans from the new endpoint — keep ID donations on

the existing POST /donate flow. Simpler, but means the frontend needs to call

different endpoints depending on the NGO's country.