#jonathanbull-invoice-failure
1 messages ยท Page 1 of 1 (latest)
For an example of an invoice that doesn't seem to comply to those docs, see in_1KWx6QHZLNwo79RqbP0pYCH0.
source is "legacy" and we don't document it since it's been deprecated for a few years, but there are still old flows that rely on it and the hosted invoice page for example does that
so you have to look at both basically, or you can look at payment_method_details on the underlying Charge otherwise
Ahhh thanks @chilly marsh . Are you able to tell from that invoice ID why it's using the legacy property?
We only raise invoices one way (as far as I can tell), and the majority of them are using payment_method.
I see this has card_123456 as the card, do you have a similar example where payment_method is set instead?
Sure, let me see if I can find one.
Try in_1KYYdMHZLNwo79RqZPDv8fUA ๐
Both of these invoices should have been raised in the same manner.
in_1KWx6QHZLNwo79RqbP0pYCH0 uses $invoice->payment_intent->last_payment_error->source.
in_1KYYdMHZLNwo79RqZPDv8fUA uses $invoice->payment_intent->last_payment_error->payment_method.
that's the thing, the second one is associated with a PaymentMethod (pm_123) and the first one with a legacy Card (card_123)
Aha. Gotcha! So the first one uses Card, likely due to the customer adding it prior to before we were using payment methods.
Thanks for clearing that up.
yeah it's complex unfortunately as we can't know what your integration expects
makes sense
if you're a new integration you don't know about source, if you're an old one you don't know about payment_method
Funnily enough we're working on rebuilding ACH Debit on PaymentMethod and I was having the same conversation with the product team just this morning about why we can't just "roll it out" and your examples are exactly what I was looking for :p
Heh, well I'm glad that was helpful . Thanks again for the excellent response @chilly marsh ๐