> ## Documentation Index
> Fetch the complete documentation index at: https://docs.wegive.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Standard Events

> When each checkout milestone fires, how GTM and Tealium deliver it, and which signals represent successful payments.

WeGive reports checkout milestones to Google Tag Manager (GTM) and, when enabled, Tealium. Your organization configures the triggers, tags, mappings, consent rules, and reporting destinations in its tracking platform. Sending an event to a container does not guarantee delivery to a destination.

These events work alongside [checkout interaction hooks](/external/onboarding/tracking/checkout-hooks). Hooks let your scripts observe individual controls; standard events report the application milestones below. Not every checkout layout or authentication path encounters every milestone.

## Enable delivery

**GTM:** configure your Google Tag Manager container in WeGive's integrations settings. Event timing, payloads, common context, and donor-sharing controls are described below. Ecommerce messages use the checkout document's `window.dataLayer`; interaction events use the GTM plugin.

**Tealium:** configure the account, profile, and environment in the Tealium integration, then enable **Send standard checkout events**. This toggle defaults to off. The environment defaults to `prod` when blank. Page-view tracking works independently of this toggle.

If your Tealium profile already listens for WeGive data-layer events and forwards them, remove that forwarding before enabling automatic delivery. Otherwise the same milestone can be reported twice. GTM and Tealium can run together; either can receive its events independently of the other.

## Event catalog

| Event | When it is reported | Payload facts |
| - | - | - |
| `begin_checkout` | Single-page initialization, or advancement from the stepper's Giving step. | Ecommerce currency, value, designation items; donation frequency. |
| `add_payment_info` | Payment-information milestone: submission in single-page checkout, or Billing advancement in the stepper. Eligibility varies by payment path. | Ecommerce currency, value, payment type; donation frequency. |
| `givingDetails` | Advancement from the Giving step. | Amount and frequency; V1 also includes currency code in `value`. |
| `personalInformationSignIn` | Checkout sign-in continuation. V1 also reports this on its guest continuation. | Interaction envelope. |
| `personalInformationSignUp` | Checkout signup completion. | Interaction envelope. |
| `giveAsGuest` | Donor chooses guest continuation. | Interaction envelope. |
| `verificationSent` | Authentication code sent. | Interaction envelope; verification type when supplied. |
| `verificationCompleted` | Authentication code verified. | Interaction envelope. |
| `paymentInformation` | Advancement from Billing. | Interaction envelope. |
| `changedNewPaymentType` | Type of payment method being added changes. | Interaction envelope; payment type. |
| `addedCard` | Card-added milestone. | Interaction envelope. |
| `addedBank` | Bank-added milestone. | Interaction envelope. |
| `addedOtherPaymentType` | Alternative-payment continuation. | Interaction envelope. |
| `confirmOneTime` | Donor chooses the one-time option at a conversion prompt. | Amount and frequency. |
| `convertRecurringYearly` | Donor chooses a recurring option at a conversion prompt. Despite its name, this event applies to all supported recurring frequencies. | Chosen frequency. This is a choice, not proof that a plan was created. |
| `donationConfirmed` | Donation-completion continuations. | Donation interaction envelope below. This is not a strict settled-payment signal. |
| `purchase` | Donation and registration ecommerce-completion continuations. | Ecommerce transaction ID, currency, value, items; donation/registration facts. This is not a strict settled-payment signal. |
| `donationSuccess` | The browser receives a transaction explicitly marked successful by WeGive, including a required verification response. | Outcome envelope below. |
| `recurringPlanCreated` | A new recurring plan is created, including a post-payment conversion. | Outcome envelope describing one configured installment. |
| `registrationConfirmed` | Event-registration completion; outside donation-only checkout. | Registration amount, currency, campaign/event/registration IDs, transaction reference, quantity, status, frequency and fee coverage. |
| `personalInformation` | Standalone password sign-in tracking; outside donation-only checkout. | Interaction envelope. |

Event availability varies between V1, V2, stepper, single-page, and payment paths. A wallet path that bypasses the `purchase` milestone does not emit that event. Its qualifying payment/plan response can produce `donationSuccess` or `recurringPlanCreated`.

No `session_start`, `login`, `signup`, `guest_login`, `donation_result`, or session-UUID-ready event is part of this catalog.

## GTM payloads

Interaction messages use the plugin serialization: `event`, `target` (category), `action`, `target-properties` (label), `interaction-type` (noninteraction), and optional `value`. Some V2 events have no label. GTM includes authentication contact fields under Existing fields only or Expanded donor details; Off suppresses them. Native Tealium does not copy these authentication contact fields; it uses its own independently gated donor fields.

Ecommerce messages use `{ event, ecommerce, donation }`. An `{ ecommerce: null }` message precedes each ecommerce event to clear previous values. Ecommerce amounts and item prices are in major currency units; `donationConfirmed.value.amount` is in integer cents.

`donationSuccess` and `recurringPlanCreated` use the `donationConfirmed` interaction envelope with these nested `value` fields:

| Field | Meaning |
| - | - |
| `amount` / `amount_dollars` | Integer cents / major units. Successful payment total including covered fees, or one configured recurring installment including configured covered fees. Never the lifetime plan total. |
| `currency_code` | Uppercase currency for that returned payment or plan. |
| `is_anonymous` / `anonymous` | `is_anonymous` is a boolean. The `anonymous` alias preserves the checkout's source value and type; use `is_anonymous` when a boolean is required. |
| `fee_covered` / `coverFees` | `fee_covered` is a boolean. The `coverFees` alias preserves the checkout's source value and type; use `fee_covered` when a boolean is required. |
| `campaignId` | Campaign ID, or `null`. |
| `designationName` / `designationId` | Primary designation name / ID, or `null`. |
| `frequency` | `once` or the recurring frequency; the plan-created event uses the created plan's frequency. |
| `transactionId` | Actual initial transaction ID, or `null` if there is no initial transaction. |
| `transactionStatus` | Numeric WeGive status, or `null`. Only `2` qualifies for `donationSuccess`. |
| `scheduledDonationId` | Actual recurring-plan ID; required for plan-created and otherwise `null` when absent. |
| `correlation_id` | Returned transaction correlation reference as a string, or `null`. Never replaced with a transaction, plan, session, or Meta event ID. |

For example, a GTM Custom Event trigger can match `donationSuccess`, with Data Layer Variables `value.amount_dollars`, `value.currency_code`, and `value.transactionId`:

```json theme={null}
{
  "event": "donationSuccess",
  "target": "Checkout",
  "action": "click",
  "target-properties": "Single Page Donation Confirmation",
  "interaction-type": false,
  "value": {
    "amount": 2600,
    "amount_dollars": 26,
    "currency_code": "USD",
    "is_anonymous": false,
    "anonymous": false,
    "fee_covered": true,
    "coverFees": true,
    "campaignId": null,
    "designationName": "General Fund",
    "designationId": 7,
    "frequency": "once",
    "transactionId": 42,
    "transactionStatus": 2,
    "scheduledDonationId": null,
    "correlation_id": "example-transaction-reference"
  }
}
```

## Tealium payloads

WeGive calls `utag.link(payload)` with the same event name in `tealium_event`. It does not specify tag UIDs or bypass your profile's routing rules. See [Tealium's tracking API](https://docs.tealium.com/platforms/javascript/api/tracking-functions/).

The payload uses flat UDO variables:

| Source fact | Tealium variable |
| - | - |
| Event name | `tealium_event` |
| Category, action, label, noninteraction | `event_category`, `event_action`, `event_label`, `event_noninteraction` |
| Donation/interaction `value` field | `value_` plus its field name, such as `value_amount_dollars`, `value_transactionId`, `value_correlation_id` |
| Ecommerce currency, value, transaction ID, payment type | `ecommerce_currency`, `ecommerce_value`, `ecommerce_transaction_id`, `ecommerce_payment_type` |
| Item IDs, names, prices, quantities | Aligned arrays: `ecommerce_items_item_id`, `ecommerce_items_item_name`, `ecommerce_items_price`, `ecommerce_items_quantity` |
| Donation frequency, anonymity, fee coverage, campaign | `donation_frequency`, `donation_is_anonymous`, `donation_fee_covered`, `donation_campaign_id` |
| Registration ecommerce facts | `donation_is_registration`, `donation_campaign_event_id`, `donation_registration_id`, `donation_status`, `donation_quantity` |

Units and scalar types match the source facts. Explicit nulls remain null; absent fields are omitted. Missing item attributes become null at their array position. The base event mapping uses a non-contact allowlist, excluding donor names, email, phone, addresses, and the destination of an authentication code. When Tealium donor sharing is enabled, separately allowlisted donor\_\* fields are added as described in the sharing guide. Custom-field answers and payment credentials are not forwarded.

In Tealium, define the relevant UDO variables and configure your tag/event mapping for `tealium_event` equal to `donationSuccess`. The preceding example is delivered with `value_amount: 2600`, `value_amount_dollars: 26`, `value_currency_code: "USD"`, `value_transactionId: 42`, `value_transactionStatus: 2`, and `value_correlation_id: "example-transaction-reference"`, along with the other permitted fields. This is an example of WeGive's automatic payload, not a second `utag.link` call to add to your profile.

## Select the reporting signal

* Use `donationSuccess` for explicit successful-payment reporting. Pending, processing, failed, missing, or unknown statuses do not qualify. HTTP success alone does not qualify.
* Use `recurringPlanCreated` to count newly created plans. A deferred plan can have no initial payment. A pending initial transaction retains its actual ID/status in this event. Updating an existing plan does not create another plan-created event.
* An immediate successful recurring gift can produce both `donationSuccess` and `recurringPlanCreated`. Count the payment and the plan as different measures.
* Avoid counting `donationConfirmed`, `purchase`, and `donationSuccess` as three separate gifts. `donationConfirmed` and `purchase` can report completion paths that are not strictly settled payments.

`donationSuccess` and `recurringPlanCreated` are deduplicated by organization, event type, and returned record ID for the current page lifetime, including component remounts. This deduplication applies specifically to those two outcome events. A post-payment conversion reports the newly created plan without repeating the initial donation-success signal.

These are browser events, not a settlement feed. A payment that settles after the donor leaves does not generate a later browser success event. Native Tealium delivery buffers at most 100 events for up to 15 seconds while its SDK loads; events can be lost if the page closes, the SDK stays unavailable, the setting/profile changes, or a vendor call fails. Events are never redirected to another organization's loaded profile.

Outcome events depend on the transaction status and plan identifiers returned by the WeGive API. The correlation reference is provided for matching records; it does not itself perform a Salesforce lookup or establish equivalence with a Salesforce receipt identifier.

## Shared context and optional identity

All standard events include the [common context](/external/onboarding/tracking/context): nested `wegive` in GTM and flat `wegive_*` variables in Tealium. Events emitted before session creation completes can contain a null UUID. [Donor sharing](/external/onboarding/tracking/donor-sharing) is independent per integration; explicit GTM opt-out also suppresses authentication contact fields. Common `wegive` / `wegive_*` context contains no donor contact fields. GTM uses separate `wegive_donor` and `wegive_user_data` namespaces in Expanded donor details mode; Tealium adds `donor_*` fields only under its own sharing setting. Context-only updates have no event key and do not fire a conversion.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.