Verify the donor passwordless verification code
Second step of the donor-portal passwordless login flow. Only the latest six-digit numeric code is accepted. Five failed well-formed attempts burn the active challenge across source IPs. On success returns the donor record, client info, session id, and saved-payment snapshot, then clears challenge state.
Body
Email entered on the verification screen. Validator rule: required|email.
Donor id returned by postPasswordlessLogin. Validator rule: required|integer.
Six-digit numeric code from the verification email. Submit it as a string so leading zeros are preserved. Validator rule: required|string|size:6|regex:/^[0-9]{6}$/.
6^[0-9]{6}$"012345"
Response
Verification succeeded.
"success"
A donor record. Donors give one-time donations and recurring commitments, and may be linked to entities (recipients) via sponsorships. Standardized profile columns (first_name, phone, address, etc.) coexist with arbitrary custom fields stored in json_fields and defined per hysform_id. The username/email/password columns also let donors sign in to the donor portal.
A Gratona client — the tenant of the multi-tenant system. Owns donors, entities, programs, users, and integrations. The client_id on every other resource scopes data to this row. Stripe Connect onboarding state, account-level settings, and the client's display name all live here.
Redis donor session id. Carry it on subsequent donor-portal requests as the {session_id} URL path parameter.
true
Raw payment-method details from the admin DonorController card lookup.
Normalized summary (id, type, brand/last4 etc.) suitable for one-click checkout.