#nancy_magdi-pm-subscription
tiny oak
Hello 👋
I'm not sure I fully grasp the question
Are you looking for the payment method that was used to pay for subscription invoice?
urban veldt
yes
tiny oak
Gotcha
So the charge on the invoice should have the information that you're looking for
https://stripe.com/docs/api/invoices/object#invoice_object-charge
https://stripe.com/docs/api/charges/object#charge_object-payment_method
hybrid tide
Hello @tiny oak
I am working with Nancy on this.
Your input is interesting, but I am afraid that for async payment methods, e.g. SEPA this won't work.
I see still "null" where I would like to see, that the customer chose sepa_debit to pay
tiny oak
do you have an example invoice ID?
tiny oak
thanks looking
hybrid tide
The reason we are asking for this is:
We would like to apply some sort of grace period to customers, who chose to pay with async payment methods. Since we are selling subscriptions, they else lose access the day after the purchase, since the money did not arrive yet (no event for "invoice.paid").
tiny oak
In that case, you can look at the PaymentIntent instead
hybrid tide
So we thought we need special handling for sepa_debit and increase the expiration date manually for let's say 14 days, and then only try to validate the subscription expiration after this (should be enough time for the money to have landed in our account).
Or is there a better way to deal with this use-case in general?
The "pi_3KxoLLDUOecS5KXz1qVXmEJs" object shows:
"allowed_source_types": [
"card",
"sepa_debit"
],
"payment_method": null,
"payment_method_options": {
"card": {
"installments": null,
"mandate_options": null,
"network": null,
"request_three_d_secure": "automatic"
},
"sepa_debit": {
}
},
"payment_method_types": [
"card",
"sepa_debit"
],
but it does not reveal which type has actually been chosen.
tiny oak
I mean at that point the customer still has a choice to make right?
So you'd likely want to listen for payment_intent.processing instead of invoice.created
hybrid tide
true,
@urban veldt this is probably what we've been looking for:
"payment_method_details": { "sepa_debit": { "bank_code": "28050100", "branch_code": null, "country": "DE", "fingerprint": "t9Lwh83RCsNl5hGH", "last4": "0905", "mandate": "mandate_1KxoLMDUOecS5KXzb8RQ1ClP" }, "type": "sepa_debit" },
so whenever the event payment_intent.processing is fired (we need to listen for this using webhooks), we can determine the chosen payment_method.
And this is best practice to deal with it, can you confirm that @tiny oak ?
tiny oak
I have to step away now but @wary osprey should be able to help you w/ your follow up
wary osprey
charge.payment_method_details.type is the canonical way to see what payment method was used for a payment, yes.
hybrid tide
great!
And there is no built-in way with stripe to have something that is called "grace period" with Apple/Google subscriptions?
wary osprey
what would that be?
hybrid tide
Meaning that if the payment bounces (or is delayed in our case of sepa_debit), the user still has access to the subscription for N given days.
wary osprey
access to the product is something you manage, and you can base it on the subscription statuses in Stripe or have more complicated logic so it's not really something we would build in
but yeah unfortunately the Billing state machines don't work amazingly with delayed payment methods like bank debits in my opinion, it's a really tricky integration
hybrid tide
As I've tried to explain above, we've experienced following issue:
-
day0: customer buys a subscription using sepa_debit
-
day0: customer get's access to our content (the expiration_date is set to the next day)
-
day1: customer loses access to our content, because the payment could not be confirmed yet (we are listening to "invoice.paid", which works great for any immediate payment method)
wary osprey
yep, that's what I mean, the state machines are not great since they're designed for cards where the subscription becomes active as soon as the first invoice is paid, for bank debits we do the same except that payment can async fail later
I'm not sure what our recommendation is to be honest, since as far as I know the debit failing a few days later doesn't change the subscription or invoice status
hybrid tide
ok, but then it seems to me we are on the right track. Now that we can identify "sepa_debit" in the CHARGE object (once it's processing), we can then manually override the expiration_date to be 14d later than stripe suggests. And during that 14d the user will NOT lose access to our content.
well should the async payment actually never arrive, our customers will just have 14d free access this way. But that's ok.
but after 14d they will expire naturally, unless the "invoice.paid" has been fired in the meantime and we can adjust expiration_date to match the actual billing cycle (a month or a year from the purchase date)
and we need to do that for any upcoming billing cycle, not just the initial payment.
That's another pain point I've noticed. Stripe starts collecting the next charge on the date of expiry. So there is another couple of days without payment in between where without a fix on our side (grace period), the customer would lose access again between every recurring billing cycle.
wary osprey
yep that all makes sense I think. I really wish I had some advice for you but this is not an area I'm well versed in beyond knowing that it's very tricky.
hybrid tide
Thank you nevertheless!