Revenue & Refund Tracking

Track successful payments and refunds using Intempt's unified Charge event — the canonical revenue event for all financial transactions.

Intempt uses a single, unified revenue event for all financial transactions. There is one revenue event name: Charge. Both successful payments and refunds use this event — differentiated only by their payload.

All revenue events must be sent from backend systems only. Never fire from the browser.

Successful Payments

Send a Charge event after payment gateway confirmation with these fields:

Field	Required	Description
`eventId`	No	Unique UUID — prevents duplicate processing. Auto-generated if omitted.
`userId`	One of `userId`, `profileId`, or `accountId`	User email or profile identifier
`amount`	Recommended	Actual charged value. Not enforced by the platform, but needed for revenue reporting to work correctly.
`status`	Recommended	Must be `"succeeded"`. Not enforced by the platform, but needed for revenue reporting to work correctly.

{
  "track": [
    {
      "name": "Charge",
      "payload": [
        {
          "eventId": "evt_charge_unique_uuid",
          "userId": "customer@example.com",
          "data": {
            "amount": 99.99,
            "currency": "USD",
            "status": "succeeded",
            "orderId": "order_456"
          }
        }
      ]
    }
  ]
}

Refunds

Use the same Charge event for refunds — replace amount with amount_refunded, keep status as "succeeded".

{
  "track": [
    {
      "name": "Charge",
      "payload": [
        {
          "eventId": "evt_refund_unique_uuid",
          "userId": "customer@example.com",
          "data": {
            "amount_refunded": 99.99,
            "currency": "USD",
            "status": "succeeded",
            "orderId": "order_456"
          }
        }
      ]
    }
  ]
}

A refund is a financial operation within the charge lifecycle, not a separate transaction type.

Rules

Always:

Send events server-side only, never from the browser
Generate a unique eventId per transaction to prevent duplication
Fire only after payment gateway confirmation
Keep userId consistent across all platforms

Never:

Create separate Purchase, Refund, or OrderCompleted events
Fire on pending, failed, or unpaid transactions
Reuse eventId across multiple transactions
Trigger from frontend/client-side code

WooCommerce Example

Hook into woocommerce_payment_complete — fires only after the payment gateway confirms the charge:

add_action('woocommerce_payment_complete', function($order_id) {
  $order = wc_get_order($order_id);

  // Send to Intempt Track API
  $payload = [
    'track' => [[
      'name' => 'Charge',
      'payload' => [[
        'eventId'  => 'charge_' . $order_id . '_' . time(),
        'userId'   => $order->get_billing_email(),
        'data'     => [
          'amount'   => floatval($order->get_total()),
          'currency' => get_woocommerce_currency(),
          'status'   => 'succeeded',
          'orderId'  => strval($order_id),
        ],
      ]],
    ]],
  ];

  wp_remote_post($intempt_track_url, [
    'body'    => json_encode($payload),
    'headers' => ['Content-Type' => 'application/json'],
  ]);
});

For refunds, hook into woocommerce_order_refunded and use amount_refunded instead of amount.

Revenue & Refund Tracking