Stripe Payment Intents
Attribute direct Payment Intents used by custom checkout, Elements, or mobile payment flows.
Use this guide when your backend calls stripe.paymentIntents.create directly. For most new web integrations, Stripe recommends Checkout Sessions with the Payment Element because it manages more checkout behavior for you.
Carry the session into payment creation
Send the Talivia session ID to the backend that owns the Payment Intent. Never create Payment Intents with a secret Stripe key in browser code.
const sessionId = window.talivia.getSessionId();
const response = await fetch('/api/create-payment-intent', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ sessionId }),
});
const { clientSecret } = await response.json();Create the Payment Intent on your server and attach the session directly to its metadata.
const paymentIntent = await stripe.paymentIntents.create({
amount: 2500,
currency: 'usd',
automatic_payment_methods: { enabled: true },
customer: stripeCustomerId,
receipt_email: customerEmail,
metadata: {
talivia_session_id: sessionId,
},
});
return Response.json({ clientSecret: paymentIntent.client_secret });Talivia listens for payment_intent.succeeded, records amount_received, and deduplicates the payment by Payment Intent ID. Payment Intents associated with Stripe invoices are left to invoice events so renewal and subscription context is not lost.
Mobile and web-to-app checkout
Pass the original web session ID through your authenticated checkout handoff or deep-link state and store it with the order on your backend. The mobile app does not need the Talivia browser tracker; the backend only needs to attach the previously captured opaque ID when it creates the Payment Intent.
Identity fallback
Supplying a stable Stripe Customer and receipt email improves matching for later payments. After login or signup on the tracked website, connect that identity:
window.talivia.identify('user_123', {
email: 'buyer@example.com',
stripeCustomerId: 'cus_123',
});Identity is a fallback and renewal bridge. Metadata remains the strongest signal for attributing the first payment to the exact checkout session.