#dionysos_webhooks
1 messages ยท Page 1 of 1 (latest)
๐ Welcome to your new thread!
โฒ๏ธ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).
โฑ๏ธ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can start a new thread if you have another question.
๐ This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1255510393435066369
๐ Have more to share? Add details, code, screenshots, videos, etc. below.
Hello
I don't think you can pass the invoice ID like you're passing right now..
Let me check what the right syntax would look like
Can you try
--override invoice:id=in_1PVgxNAotHECEdB6z8ZLO0c6 \
--override invoice:customer=cus_QMPm8fmp1p6Xgf```
./stripe.exe trigger invoice.paid --override invoice:id=in_1PVgxNAotHECEdB6z8ZLO0c6 --override invoice:customer=cus_QMPm8fmp1p6Xgf
Setting up fixture for: customer
Running fixture for: customer
Setting up fixture for: payment_method
Running fixture for: payment_method
Setting up fixture for: invoiceitem
Running fixture for: invoiceitem
Setting up fixture for: invoice
Running fixture for: invoice
Trigger failed: Request failed, status=400, body={
"error": {
"code": "parameter_unknown",
"doc_url": "https://stripe.com/docs/error-codes/parameter-unknown",
"message": "Received unknown parameter: id",
"param": "id",
"request_log_url": "https://dashboard.stripe.com/test/logs/[REDACTED]?t=1719407766",
"type": "invalid_request_error"
}
}
hmm.. thinking..
Can you share more context about what you're actually trying to do by triggering the event?
I don't believe you can override these values. The only way would be to use --edit flag and edit the fixture to do what you want to do OR write your own fixture for this
If you share your exact usecase then I can probably offer a workaround
Well very simple, I am trying to mock an event with existing data, i.e., a test customer and invoice with whom I already made a test purchase / basically replay this purchase to troubleshot my handler
Gotcha. If you only care about receiving the event and using it to mock data then rather than triggering this via CLI, you can just pay the invoice via the dashboard or use stripe invoices pay in_123
That should generate an invoice.paid event
I would like to trigger a specific event via the CLI
The trigger feature seems quite limited in offering customisation
โฏ ./stripe.exe trigger invoice.paid --override invoice:id=in_1PVgxNAotHECEdB6z8ZLO0c6 --override invoice:customer=cus_QMPm8fmp1p6Xgf --edit
Waiting for your editor to close the file...
exec: "vi": executable file not found in %PATH%
I am on Windows
huh your terminal is probably not configured to use vi editor. This work for me:
stripe trigger invoice.paid --edit
Circling back to your usecase, I don't think using stripe trigger is the right approach here. If you're trying to test your webhook by "replaying" the same event then you should really just use stripe resend command which sends the same event to the webhook endpoint (as long as the event is within 30 days)
The problem with resend is that it is not forwarded to my local listener...
Can you share the event ID?
You can't pass a URL to --webook-endpoint
This is the eventId: evt_1PVgxRAotHECEdB6tsoNyEkC
I really need help with getting this to work - I can't deploy to prod without extensive testing first
The event type is invoice.payment_succeeded but your CLI is only listening for payment_intent.succeeded
This is the correctevent: evt_3PVgxNAotHECEdB60EB32hc0
Can you show side by side screenshots of the attempt as you've done here but with the right event ID?
#1255510393435066369 message
You can't pass a URL to --webhook-endpoint parameter
Can you remove that and try again?
Working now ๐
๐
Thanks - side question, what is the best event to listen to to be sure of successful payments before sending licenses to customer? invoice.paid or payment succeeded?
invoice.paid is generated when the actual invoice is marked as paid. payment_intent.succeeded is generated when the customer's payment succeeds.
Depending on what matters to your usecase the most, realistically you can use either of the events
ok so is it just a matter of what information I need to process?
Correct
also since I have you on the chat, I am trying to come up with a way of getting an id per item, like if I enable purchasing more than 1 item per subscription I cant really use the paymentId as I need an ID for each item, what do you recommend using?
This is what I came up with, but it is not ideal:
paymentIdWithIndex = `${livemode ? "" : "test-"}${
quantity > 1 ? `${paymentIntent.id}-${i}` : paymentIntent.id
}`;
I would rather use a stripe id.
Can you tell me more about what you mean by that? Our subscription payments do ultimately boil down to one payment intent that gets paid. The invoices have line items which have IDs, which could help you differentiate them
So to make it simple, I generate licenses per item purchased, so although it is the same subscription if two products are purchased I will generate two licenses - just thinking which type of stripe id I could use to distinguish the licenses or know how many I need to generate, so far I have a very hacky solution of getting the invoice, checking the quantity and iterating over the quantity to append the index to the paymentId
this solution is very hacky and less than ideal
Honestly I don't think there is a good Stirpe ID to do this with as that isn't how we conceptualize invoicing. Typically the way to do this would be to have two licenses on your side but they point to the same Stripe subscription and you check the status of that to check whether they have been making payments on time.
IMO each item purchased should have its own ID
not just a quantity and invoice object but item should be children of an invoice
would open up more use cases
- like mine -
They do have their own line item ID, they just don't have separate payment IDs because they are part of the same payment. You can still acheive use cases like yours, the logical mapping from your end just needs to be a bit different.
Its only one line for my case though
just different quantity
as it is the same product bought X times
Ah gotcha, so yes you need to do a many to one mapping here
Exactly, what is the guidance on that? So far I have just hacked my way by appending an index to the paymentId but it is less than ideal.
Not sure what you mean, can you tell me more about what you are doing now and where you are stuck?
Something like that:
const [customer, invoice] = await Promise.all([
stripe.customers.retrieve(paymentIntent.customer),
stripe.invoices.retrieve(paymentIntent.invoice),
]);
const quantity = invoice.lines.data[0].quantity;
const licenses = [];
for (let i = 0; i < quantity; i++) {
const paymentIdWithIndex = `${livemode ? "" : "test-"}${
quantity > 1 ? `${paymentIntent.id}-${i}` : paymentIntent.id
}`;
const license = await createLicense(
paymentIdWithIndex,
--- SNIP ---
);
await saveDataToDashboard(database, paymentIdWithIndex, {
--- SNIP ---
});
licenses.push(license);
}
This is working as it is, but again I would rather use a Stripe ID rather than:
const paymentIdWithIndex = `${livemode ? "" : "test-"}${
quantity > 1 ? `${paymentIntent.id}-${i}` : paymentIntent.id
}`;
Ah, gotcha. Unfortunatley that isn't possible at the moment so for now it would be best to differentiate with -1 and such
Ok last question, I am considering allowing users to edit the product quantity in their subscription, however they should not be able to reduce their current count - as no cancellation is supported - also wondering if they add additional product would that emit a payment_succeeded as this is the event I am listening to to issue licenses
Unfortunately our customer portal doesn't support that functionality at the moment. I think you can restrict what quantities a customer can choose between but there isn't a way to prevent them from decreasing the quantity if there is a valid lower quantity
So you would need to write your own page that updates subscriptions to properly enforce that restriction
To answer your other question: if the user changes their subscription and makes a payment on it, you will get the normal payment succeeded events. So you can listen to those events to properly react to those updates if you do use the portal
Unfortunately our customer portal doesn't support that functionality at the moment. I think you can restrict what quantities a customer can choose between but there isn't a way to prevent them from decreasing the quantity if there is a valid lower quantity
That a big drawback - because for my use case once a license generated it is for a set time, it cannot get invalidated hence why I cant allow to reduce quantity but only increasing it.
I guess I just need to leave the multiple subscription option enabled then
But thats maybe something that can get added to the backlog from your side
Yep if you write in to our support team you can put in a feature request https://support.stripe.com/?contact=true
Find help and support for Stripe. Our support site provides answers on all types of situations, including account information, charges and refunds, and subscriptions information. Get your questions answered and find international support for Stripe.
Alright cool and lastly, a thing I am not sure about, if I enable 3D secure but dont enable sending emails, what happens?
Do they use their bank app to confirm the payment instead?
and if I enable email, they dont receive notif on their bank app but have to check their email instead?
This is not well documented the behaviour around these options
Our emails do not effect whether they get a notification from their banking app. Some banks may automatically notify their cardholders (I am actually not aware if this happens at all) but they don't rely on any signal from Stripe to do so. We reccommend either turning the email setting on or sending your own emails if you have it off
but if email turned off which confirmation takes precedence - the one from banking app with biometrics, or the click on the allow in the email?
From your perspective, all that is happening is that the payment intent is successfully confirmed. The Stripe email will redirect the user to a page where they can complete 3DS on their bank's site, so that would be the same as the user completing it on their bank's site otherwise
So even if it is possible for this to happen two different ways, you get the same invoice.paid webhook event either way
ok I am just afraid that users will receive a double notification - both the email and the bank app notification - not ideal for UX.
If you write in to our support they may know if banks do that at all. I have not heard of that happening and I do know that without these emails many customers won't receive any notification at all and the payment will fail. So that is the downside of turning these emails off either way https://support.stripe.com/?contact=true