Connect any payment system to acquisition data.

Send normalized purchases, renewals and refunds through the Payment API with the visitor or session ID that links each payment to its journey.

Send one durable billing event

Your backend posts the provider, transaction ID, amount in minor units, currency and event type. Purchases, subscription starts, renewals, upgrades, downgrades, refunds, cancellations and churn use the same normalized shape.

Use stable IDs when requests are retried

The API enforces idempotency with project, provider and transaction ID. Reusing the same durable billing ID returns a duplicate status; generating a new random ID for each retry defeats that protection.

Accept revenue without inventing a source

Visitor and session IDs are optional for storage but necessary for a direct journey lookup. When they are missing or do not resolve to a prior event, AttribIQ stores the payment and writes an attribution fact with empty acquisition fields.

Minimal Payment API request

Amounts use minor units. In this example, 2900 EUR means €29.00.

POST /v1/revenue
Authorization: Bearer <project-api-key>
Idempotency-Key: txn_123

{
  "provider": "custom",
  "transaction_id": "txn_123",
  "event_type": "purchase",
  "amount": 2900,
  "currency": "EUR",
  "visitor_id": "v_abc",
  "session_id": "s_def"
}

Questions buyers ask

Which event types are accepted?

purchase, subscription_started, renewal, upgrade, downgrade, refund, cancellation and churn.

How are refunds stored?

A positive refund amount is normalized to a negative revenue amount so totals can report net revenue consistently.

Can I omit the visitor ID?

Yes, but the event may remain unattributed unless the session ID or another implemented lookup provides a reliable match.

Send a test event with a known session

Use an ID returned by the browser attribution API, reuse the transaction ID on a retry, and confirm that the second request is treated as a duplicate.