#Gironimo4-webhooks
viscid ocean
Hi there 👋 webhook events are usually a good fit for being notified of completed actions and performing any necessary steps on your end:
https://stripe.com/docs/webhooks
https://stripe.com/docs/billing/subscriptions/overview#subscription-events
neat cobalt
I have looked at the webhooks page before, I can definitely take a deeper look at the subscriptions page, but does POST data that isn't part of Stripe's API get cached in the $payload? (Sorry using PHP to be clear). I haven't seen First Name, Last Name, or Password come through when decoding any of the JSON packages from checkout, so not sure how those persist
viscid ocean
Apologies, not sure why I jumped to conclusion that you were using subscriptions.
If the information is being provided on Stripe objects (such as the Customer) then it should persist. Additional information can be passed in via metadata but the idea of using this to hold a password doesn't seem like a good one:
https://stripe.com/docs/api/metadata
neat cobalt
So would I be able to do something like this with my Checkout?
$('#order-form').submit(function(e){
e.preventDefault();
stripe.redirectToCheckout({
lineItems: [{
// Define the product and price in the Dashboard first, and use the price
// ID in your client-side code. You may also pass a SKU id into the price
// field
price: planId,
quantity: 1
}],
mode: 'subscription',
** metadata: ['FirstName' = $firstName],**
successUrl: 'https://www.example.com/success',
cancelUrl: 'https://www.example.com/cancel'
});
viscid ocean
Oh, you're using the client-only approach. No this approach doesn't support metadata, nor could you rely on it as a savvy user could manipulate your page's javascript and change the values that would be returned.
neat cobalt
Hmmm, what should I be doing instead? I'm sorry I am trying to migrate from a legacy version (and I've followed the https://stripe.com/docs/payments/checkout/migration page) but I have been struggling with it, which you don't seem surprised by with me using the client-only approach
viscid ocean
We recommend our Client-Server approach when using checkout sessions as it enables more capabilities:
https://stripe.com/docs/payments/accept-a-payment?integration=checkout
In this approach you created the Checkout Session on your server, and then the Client-side simply handles a redirect to the hosted page.
neat cobalt
OK, and then the session holds all of my customer's variables (name, password, etc), and then when finished stripe puts in the customer ID or whatever info needed to authenticate it?
viscid ocean
If your backend needs information from your page, then I'd recommend your site send it there explicitly rather than using Stripe as a middle-man.
neat cobalt
Sure, that makes sense, but how do I connect whatever that information is with the stripe payment info? Would I just put in a webhook that if customer.subscription.created then take the email through a SQL request and see if it matches anything in my database? Sorry for these conceptual questions, these are the things I've been trying to do on my own, but I just don't have the experience to be able to know I've got it all down
viscid ocean
That's going to depend on the structure of your model. If you're only allowing users to have a single subscription, then that could work. If you let them have multiple subscriptions then, email address alone may not be enough to identify the right DB entry and you might to generate unique identifiers.
Also when listening to webhook events, you will likely want to use it just as a trigger and then retrieve the subscription record, to ensure you've viewing the most up-to-date information, to check that the status is active to ensure payment was successful.
neat cobalt
OK, thank you very much, I will give all of this a try
viscid ocean
Happy to help!