How do I report purchases through Stripe or PayPal?

For everyone whose purchase ends at Stripe or PayPal: courses, software, services, small shops without a shop system. Metrunio accepts the payment provider’s webhooks, checks their signature and reads amount, currency, time and refunds from them.

Stripe

1. 01In the portal, add a connection for Stripe and your website under “Data connections → Payment providers”. Metrunio shows you an address.
2. 02In Stripe, add an endpoint with this address under “Developers → Webhooks” and choose the events checkout.session.completed, checkout.session.async_payment_succeeded, invoice.paid and refund.created. Without invoice.paid, your subscription renewals are missing.
3. 03Copy the endpoint’s signing secret (starts with whsec_) and enter it on the connection. Only then does Metrunio accept messages.

PayPal

1. 01In the portal, add a connection for PayPal and your website.
2. 02In your app in the PayPal developer area, add a webhook with the address under “Webhooks” and choose PAYMENT.CAPTURE.COMPLETED and PAYMENT.CAPTURE.REFUNDED.
3. 03Copy the webhook ID and enter it on the connection. Metrunio checks every message against the certificate PayPal signs with.

So that purchases are attributed

A purchase lands in the journey if it carries the reference from the SDK. With consent to analytics it contains the visitor ID, the session and the consent state. If someone declined or withdrew consent in the banner, it carries only that status (mtr1_d) and no ID. Before any decision there is no reference.

• Stripe Payment Links, Buy Buttons and Pricing Tables: nothing to do. The SDK sets the reference itself as client_reference_id. If you already use the field yourself, your value stays; what that means for your purchases is explained below.
• Stripe Checkout with your own code: pass client_reference_id: metrunio.paymentReference() when you create the session (handed from the browser to your server).
• PayPal buttons: pass purchase_units[0].custom_id: metrunio.paymentReference() when you create the order.

// Browser: get the reference and hand it to your server
const reference = metrunio.paymentReference(); // null until a decision is made

// Server (Stripe Checkout)
const session = await stripe.checkout.sessions.create({
  mode: 'payment',
  line_items: [...],
  success_url: 'https://www.example.com/thanks',
  ...(reference ? { client_reference_id: reference } : {}),
});

With no reference at all, the purchase still counts: as measured revenue, not attributed, like any order without a consent decision. Do not also report the same purchase from the browser; the order number is the payment at Stripe or PayPal, and a second report with a different number would count twice.

If your shop uses the field itself

If client_reference_id at Stripe or custom_id at PayPal carries a value of your own shop, the reference from the SDK is missing. Whether the customer declined in the banner cannot be determined then. Metrunio therefore treats such a purchase like one after a refusal: with the additional instruction for revenue reconciliation activated, it counts as measured revenue without any ID and is never attributed. Without it, Metrunio does not accept the purchase. The payment connection in the portal then shows a notice with the date of the last such purchase. Only that date is stored for this, not your value. If you want to see these purchases, give the additional instruction or pass the reference from the SDK instead of your own value.

After a refusal or withdrawal

• If the purchase carries mtr1_d, it counts as an order after a refusal. With the additional instruction for revenue reconciliation activated, it counts as measured revenue without any ID and is never attributed. Without it, Metrunio does not accept the purchase, and the connection’s log shows it as rejected.
• If someone withdraws consent in the banner, the SDK replaces the reference on Payment Links, Buy Buttons and Pricing Tables with mtr1_d. If you fetch the reference in your own code, ask for it when you create the checkout, not when the page loads.
• If the checkout was created with consent and the payment only arrives after the withdrawal (for example by direct debit), Metrunio does not accept the purchase. It does not go into revenue reconciliation as an order without a decision either.
• A refund carries no reference. It is booked against the payment without any ID and only changes a purchase that Metrunio accepted.
• If Metrunio rejected the purchase, it also discards its refund: the refund is not stored, does not appear under “Data status” and does not turn the connection red. The connection’s log lists it as “does not count”, without an order number. For this, Metrunio keeps only a checksum of the payment for 180 days when it rejects the purchase, not the payment itself. If the refund arrives before the purchase, it waits without any ID until the next processing attempt and is deleted then.
• Two exceptions: if the refund only arrives after those 180 days, or names a different identifier than the purchase (such as only the charge), Metrunio does not recognise the rejected purchase. The refund then waits 24 hours without any ID for a purchase like every refund, is deleted afterwards and only counted under “Data status”, without an order number.
• A rejection after a refusal or withdrawal is intended. The log lists it as “rejected”, but the connection does not show an error because of it.

What is read and what is not

• Read: the payment ID, amount, currency, time, for Stripe also tax, shipping and discount, the subscription ID and the reason for an invoice, and the reference.
• Not read: names, email and postal addresses, payment and card details. The message itself is not stored.
• The connection’s log shows the last 50 messages with type, outcome and amount, without order numbers, and keeps them for 30 days.

• Paid checkout sessions count, including the first payment of a subscription, and completed PayPal payments. A checkout without an amount (such as a trial) does not count.
• Since 16 October 2026, subscription renewals count as renewals (invoice.paid with billing_reason subscription_cycle): measured and shown separately in the reports, but not attributed to a channel, because an invoice carries no reference from the browser. Other invoices, for example after a plan change, do not count, and neither do subscriptions through PayPal. The article on subscription renewals has the details.
• With Stripe, a direct debit counts only once it is paid (checkout.session.async_payment_succeeded).
• Metrunio does not always find refunds of a subscription payment, because Stripe books them against a different payment than the checkout session. After 24 hours without a purchase Metrunio deletes them and only counts them per day under “Data status” (REFUND_WITHOUT_PURCHASE), without order numbers.
• Metrunio matches a refund via the payment intent, even if Stripe only includes it in the charge. If a refund names only the charge, it finds no purchase: the checkout session does not name the charge, and Metrunio does not query Stripe. This affects payments without a payment intent, which Stripe Checkout does not create.
• One webhook per website and provider. Several websites with one Stripe account need one endpoint each.