#codyl-charge
1 messages · Page 1 of 1 (latest)
Sure
that is the charge that I'm looking at
The issue is that I'm not provided the source id via a documented field. It should be in payment_method, but that is null. "source": {} has it but is undocumented and set for removal
For card transactions payment_method is set to the source id of the card
It is also properly populated for ACH Credit Transfer charges https://api.stripe.com/v1/charges/py_1KU4fkKUbaLgbekLZ3upVQpL
feels like a bug that it isn't set on ach debits
ACH Credit Transfer do not exist on the PaymentMethod API today
only on Sources, so payment_method: null is normal
this is a debit
same for ACH Debit
nah ACH Credit is only on Sources, unless you're in a beta
Ultimately: you should never have to look at the PM, what are you trying to do?
trying to get the source id of the charge
the actual response returns a source object but that is not documented and it is called out in the java api as legacy and due for removal
So the charge object is missing a documented way to get the source id of the charge for ach debits
from what I'm seeing
but not documented right?
is the docs just wrong for Charge?
and says to use payment_method instead
did someone they just get a little ahead of themselves removing the source from the Charge object docs before other things were put in place to fill the gap?
otherwise I don't see how to get the bank account id (source) of the charge using documented api's
that is getSource() and returns a PaymentSource that you can cast in a BankAccount to access its information
but that isn't listed in the docs for Charge and the comment says it is legacy and to use payment_method
I mean obviously I can use it, but seems like either the docs for Charge are wrong or payment_method should have a non-null value
using it seems like I'm just setting myself up for breakage
neither is wrong, nothing will break in any way
PaymentMethods are the new abstraction, they are great. But they don't support some old flows yet like ACH Debit, so when that happens payment_method: null is returned and you read source: { id: 'ba_123', object: 'bank_account', ...} and it just works. It's all just due to the fact that we haven't migrated that flow yet (we're working on it though) and every user of ACH Debit has to do that
once we introduce ACH Debit on PaymentMethod, we will continue to populate source: xxxxx and won't break you, but we will also populate payment_method.
OK I'll just use the old undocumented field for now
don't like seeing it missing from the docs, but is what it is
99% of integrations never need this field. You're in the 1%. The 0.1% really
We could document it, but then 99% of developers would wonder what's up with source versus payment_method (what they used to ask constantly)
gottcha
I agree we could do a better job marking it as deprecated and calling out the cases where it's still useful
thanks for the help.
If it helps: ACH Debit on PaymentMethod is happening really soon so then you can migrate and ignore this forever 🙂
tha would be great that is what is holding back from using it on cards
since we don't want to have both ways implemented on our side
I'll keep monitoring for updates on when ACH debit is supported by payment methods.
have a good rest of your day
I highly recommend using it on cards to start honestly but yeah it's a few more weeks hopefully (hoping I don't jinx it by saying that lol)