Test Apple Pay and Google Pay on the devices donors use

Apple Pay donations for nonprofits should not be tested by looking for the same button on every laptop. Digital wallets are conditional payment paths. Test one eligible Apple path, one eligible Google path, and one deliberately ineligible path; then verify that wallet visibility, payment completion, and the resulting gift and receipt records agree.

Define the three expected paths

Apple's nonprofit guidance says an organization needs a payment provider, Apple Pay implementation, and approval to accept donations with Apple Pay. If your fundraising platform manages that setup, ask it which requirements it handles and which devices it supports. Do not copy a direct-integration checklist into a managed platform account and assume the steps are identical.

Google uses a readiness check for the current device, browser, and allowed payment methods. Its current `isReadyToPay` documentation makes the important point for an operator: a visitor can be eligible on one path while another visitor is not.

Write three expected outcomes before you test:

1. Apple path: a supported Apple device and browser with a usable wallet should show the Apple Pay route.
2. Google path: a supported device and browser should expose Google Pay when the configured payment methods are available.
3. No-wallet path: a device or browser that is not eligible should still offer the payment fallback your form promises.

The third path matters. A missing wallet button can be correct. A missing wallet button plus no usable fallback is a checkout failure.

Record what the donor can actually do

Use a private test form or your platform's supported test method when available. If the only valid proof requires a live gift, follow your organization's approval and refund procedures rather than improvising repeated charges.

For each path, record the device family, browser, form URL, embedded or hosted placement, and expected wallet. Then observe the sequence without assuming that a visible button proves the path works:

• Does the expected wallet appear?
• Does selecting it open the correct payment sheet?
• Does the amount, frequency, and fund or campaign context remain correct?
• Can the donor cancel the wallet sheet and choose another payment method?
• After completion, do confirmation, payment status, gift record, and receipt agree?

This is narrower than a full donation-form launch test. The wallet test isolates conditional visibility and the return from the payment sheet. The broader launch test still owns confirmation, receipt, attribution, and staff-record checks across every enabled payment route.

Test the exact placement you will promote

A hosted page and an embedded form can behave differently because the embedded version also depends on the surrounding site. Google's current web tutorial notes that a checkout loaded in an iframe needs the appropriate `allow="payment"` permission, including on nested frames. That is an implementation clue for the technical owner, not a request for a fundraiser to edit production code during a test.

If the wallet works on the hosted page but not in the website embed, preserve both URLs, the device and browser, and the observed difference. Give that packet to the platform or website owner. The embedded-versus-hosted guide can help you choose a temporary fallback while the embed is repaired.

Do not test a generic demo and then promote a campaign embed. Test the actual placement, amount choices, frequency, designation, and surrounding page that donors will use.

Keep another payment route visible

CharityStack's current Raise page lists Apple Pay, Google Pay, cards, and bank transfers, prioritized by device. That wording sets the right expectation: the checkout adapts to the device; it does not promise every method in every session.

Your pass condition should cover both eligible and ineligible donors. On an eligible path, the wallet completes and produces the expected records. On an ineligible path, the form explains nothing falsely, leaves a usable card or bank route, and still preserves the donor's selected amount, frequency, and designation.

Avoid publishing claims such as “one-tap giving for everyone” after testing one phone. State the methods your platform supports, then let the checkout present the methods available to that donor.

Close the test with evidence

The test is ready to close when all three rows have an expected result, an observed result, and an owner for any mismatch. A wallet-visible-but-failed row is not a pass. A completed payment with the wrong gift context is not a pass. An ineligible row with a working fallback can pass even though no wallet button appears.

Keep the matrix with the form's launch evidence. When the platform, website embed, or payment configuration changes, rerun the affected rows instead of assuming yesterday's device path still behaves the same way.