import type { ButtonOptions, FraudSession, OpenResult, OrgBranding, PayframeFields, PayframeMountOptions, WeGivePayConfig } from './types'; import { type UtmSet } from './utm'; export * from './types'; export { WeGivePayError } from './api'; export { serializePopupQuery, parsePopupQuery, donationContextFromQuery, encodeTheme, decodeTheme, mergeBrandIntoTheme, UTM_PARAMS, } from './protocol'; export type { PopupQuery } from './protocol'; export { resolveUtmSet, parseUtmFromSearch, sanitizeUtmSet } from './utm'; export type { UtmSet } from './utm'; /** WeGive Pay SDK. * * Two product surfaces, neither of which can charge a card from the browser: * * 1. **Pay With WeGive button + popup** — `pay.mountButton()` / `pay.open()`. * Opens a hosted checkout where the donor authenticates as themselves * and either picks a saved payment method or adds a new card. * The button auto-pulls the org's brand (primary color + logo) from * `/api/pay/sessions`; the embedder supplies the CTA copy via `label`. * * 2. **Payframes (tokenization only)** — `pay.payframes.mount()`. * Mounts secure WeGive payframes (iframes) inside the host page. * Calling `.tokenize()` returns opaque tokens that you POST to YOUR * backend, which then calls * `POST https://api.wegive.com/api/pay/transactions` with your * organization's secret WeGive API key. The SDK itself has no * charge method by design — that's the security boundary. */ export declare class WeGivePay { readonly config: WeGivePayConfig; static init(config: WeGivePayConfig): WeGivePay; private api; constructor(config: WeGivePayConfig); /** Render the "Pay With WeGive" button into the host element. * Branding (color + logo) auto-resolves from the org behind the PK; * the embedder supplies the `label` (required). */ mountButton(target: string | HTMLElement, opts: ButtonOptions): { unmount: () => void; }; /** Open the popup programmatically (e.g. from a form submit handler). */ open(opts: ButtonOptions): Promise; /** Eagerly fetch the org branding (without rendering a button). Useful * for custom integrations that want to read `organization.name` / * `organization.primaryColor` and render their own UI. */ fetchBranding(): Promise; /** Mint a fresh server-side fraud session. Payframes call this implicitly * through `mount()`, but advanced integrations can call it directly when * they create their own server-side checkout attempt. */ createFraudSession(opts?: { checkoutAttemptId?: string; }): Promise; /** * The resolved UTM attribution set for the current page (WEG-7657): the values you * pass, otherwise whatever `utm_*` params are on the live page URL. * * **The SDK reads no cookies and writes none.** Persisting attribution past the * current URL is yours to own — you know your cookie names, their scope, and your * visitor's consent state. Pass what you stored as `explicit` and it wins. * * The popup surface applies this resolution automatically. **Payframes integrations * must forward the result themselves** — the SDK is not in that charge path, since * your own server calls `POST /api/pay/transactions` with your secret key: * * ```js * const utm = pay.getAttribution(myStoredUtm) // { utm_source: 'newsletter', … } * await fetch('/my-server/donate', { body: JSON.stringify({ token, ...utm }) }) * ``` */ getAttribution(explicit?: UtmSet): UtmSet; /** Payframes namespace — tokenization-only surface for fully custom * donation UIs. The host page never sees the underlying card data; * `mount()` injects secure iframes and `tokenize()` returns opaque * tokens you post to your server. */ payframes: { /** Mount payframes into the host page. The vault config is fetched * from `POST /api/pay/sessions` per request — never shipped in the * SDK bundle. That session also returns a server-minted fraud session * which `tokenize()` carries as `fraudSessionId`. */ mount: (opts: PayframeMountOptions) => Promise; }; private assertOriginAllowed; } declare global { interface Window { WeGive?: { Pay: typeof WeGivePay; }; } } export default WeGivePay;