#jarrett-invoice-payment
1 messages · Page 1 of 1 (latest)
hey there, i recall we were speaking yesterday, are you still facing the same challenges or are you modifying your integration?
i decided to just finalize invoices. but i want to save the card to the customer when they pay with the payment element
hmm let me see if this is possible
Can you share one of your example paid invoices?
or payment intents
in_1JnUPfF6KG2nMs1lIfEYDHX8
I figured out a potential work around but it's not really nice. it requires another API call on top of the already too long process I have since I have to create an invoice item, then an invoice, finalize it and then update the payment intent's setup_future_usage field to be "off_session".
Right, so this isn't support the same way as with payment intents directly, for similar invoice-specific reasons
You'd need to collect the payment method details separately to attach to the customer -- is that what you were referring to?
i mean the only reason I was switching to using payment intents generated from the invoice was because I thought the invocie would generate a payment intent with the proper payment options. but now i'm learning it doesn't do that either
the enabled payment methods on my account don't even get put on the payment intent
Hm yea this could work, just make sure you restrict the invoice payment_settings[payment_method_types] to cards, otherwise your defaults might include some payment method that dont work with future usage
again i'd really encourage you to revisit how you have this set up, but that's your choice
the invoices created don't even follow what the docs say though....
it says when an invoice is created the payment method types will be set using your accounts invoice settings
they are, but you can override it
i'm not overriding it is my point
i believe I also elaborated why we have to use invoices. we send enterprise customers invoices that are paid out of band, paid via wire etc
not using invoices would mean we'd need multiple different payment flows for these things
invoices may be overkill for this part of our process but when you consider having many different processes to accomplish the same one thing... that's really a lot more involved. being able to use the same flow to handle them all significantly simplifiest things.
@hardy bough while I understand, you are definitely trying to shoehorn your flow on top of an API not exactly built for it
sure, i see how it's not perfect but the last thing I'm discussing is the main reason i've tried to change from setup intents
right now we have no issues with using setup intents
but I figured I should use the payment intent generated by the invoice so I could get the payment method types that stripe thinks I can use to pay this invoice
but it's not doing that...
i've sorted the payment intents issue by modifying it after the invoice created it to have setup_future_usage which I feel isn't that odd of a thing for someone to want to do with an invoice.
Agreed, we could have decided to save the PaymentMethod automatically with the Invoice's PaymentIntent but we didn't, often because that doesn't really apply to one-off invoices that would be either paid via bank transfers (re-usable source already existing) or paid on the hosted invoice page
You have figured out the work around though, so what is blocking you with the payment_method_types exactly?
we are not setting a default payment method, it's not a sub and I don't see what the customers default payment method would have to do with this. but it's not using the invoice template settings to generate the right options
invoice generated via stripe panel (in_1JnUuwF6KG2nMs1lrv5TuhE4)
invoice genreated via API (in_1JnUwNF6KG2nMs1luF5QOCwP)
I can't figure out why my API generated invoice doesn't get all the available payment options that my stripe panel generated one gets.
regarding this specifically I was just surprised it's not an option. I find it odd that you guys have setup specific options you can pass through to the payment intent rather than just allowing users to create their own payment intent to associate with an invoice since that would allow full customization and allow users a whole lot more flexability.
I'm still struggling to follow. https://dashboard.stripe.com/test/logs/req_4oDeeNeM2uXjEs clearly shows payment_settings: { payment_method_options: null, payment_method_types: null }, and that's the one from the Dashboard right?
it would appear to be
Sorry, you are deep down a long running rabbit hole and I'm only coming up to this so I need a bit more really specific details with exact information, what you see in the raw JSON of each object and which object it is
let me pull the raw object up cause I was just going by what the payment element is displaying and what shows in the stripe dashboard
I do see https://dashboard.stripe.com/test/events/evt_3JnUvIF6KG2nMs1l1W8fzS7m that shows the underlying PI for the Dashboard invoice has N payment method types
while https://dashboard.stripe.com/test/events/evt_3JnUwOF6KG2nMs1l0IEEXrH1 (the non Dashboard one) only has a subset.
that's your bug right?
that's correct
idk if it's a bug or something I'm doing wrong
i don't like to point fingers unless I'm certain haha
when I generated my invoice from the API the only specifics I am passing in is the following
customer: @customer.stripe_id,
auto_advance: false,
payment_settings: {
payment_method_options: { card: { request_three_d_secure: 'any' } }
},
metadata: {
credits: credits,
cpe: cc.get_cpe.amount,
auto_refill: auto_refill
}.merge(metadata)
}```
payment_method_options: { card: { request_three_d_secure: 'any' } } you really shouldn't do that without explicitly setting card as a payment_method_types either
I do think it's a bug but it's unlikely to be something we can fix quickly
give me 15 minutes to repro, will take a while
the only reason we force 3DS at all is because we've had fraud attacks that stripe wasn't showing it for
and we had no choice but to force 3DS
Radar was letting fraudsters spend $1,200 x 3 times in 5 minutes and Radar was like "we'll give that a score of 6"
if we just set all the possible payment method options will the system eliminate ones that can't work. I don't know if it will allow me to set something like sep_debit on a USD invoice or if it will error out on me. i would have to somehow build a map of what payment methods every invoice could possibly use which I don't even know how that's determined beyond the simple example for sepa i just gave
sure but you are not supposed to pass a payment_method_options without explicitly passing that type in payment_method_types
I do think this is because the Dashboard uses a custom API /v1/invoice_drafts and it inherits payment_method_types differently
i'd love to use the custom api that allows me to do so much more 😂
I have confirmed I reproduce the same issue so it is a "bug" (or limitation)
My advice is: just be explicit about the payment method types you want to support. Doesn't that work if you explicitly set it?
I don’t know what I can set. Can I set them all and it will accept it? Like I said what happens if I set some that aren’t supported?
I don’t know if that’s a reasonable thing to do with the API. And I don’t have some map of every payment method and the limitations.
we accept payment in like 7 currencies
no it will error, you have to hardcode them, no way around it
how do I know what’s supported?
that’s less than ideal. is it currency based or are there more limitations than that?
😅
It's currency based, depends on the country of your account, each PaymentMethod has custom requirements and min/max amounts
well I'm candidly saying it won't be, not soon
like you can report it and we can look but I don't see why we'd prioritize this really specific edge-case
so you do have to work around it
Is it really an edge case?
yes
where do I report it?
I’m just confused how it’s an edge case when the docs literally say it should do that
https://support.stripe.com/contact is where you'd report the bug.
I'll flag it too, I'm just being honest. I could say "of course we'll look" but that won't really help you right now
I appreciate it
additionally what’s odd is that sepa debit was included. Is there something special about that vs the others?
I don't know I'm sorry. My account gets Alipay by default and I don't understand why either (but my account has a lot of secret stuff 😅 )
lol
I noticed other weird stuff like not being able to pass in card_present. which I don’t even know what that does but it errored too
I saw that option and was hoping it was how I get existing cards in the payment element but could never get the API to accept it
Oh it’s for terminal I see
well I’ve gone mobile but once I’m back on a computer I’ll try and put a detailed report together and pray cause otherwise I don’t see how we could realistically figure out what payment options would be good. Seems like trying to do it ourselves would be very error prone.
Probably have a better chance reverse engineering the dashboard request lol
are those endpoints “undocumented” or “not allowed to be used”.
you can't use them, they won't work
they only work with the Dashboard and you absolutely should not use them
👍
huh that's even weirder since it's already nil no?
i mean not setting it and sending it as nil aren't the same technically
fair
no i'm wrong again
lol
it actually isn't broken either
it's smarter than both of us haha.
those payment methods need "collection_method" of "send_invoice"
so it works exactly as it should
when I was trying to test other methods I changed it to create the invoice with that option
ohhhh
duh
but still I should have SEPA then and I only get Alipay
haaaaaaaaaa I don't like those Dashboard settings 😅
is your invoice in EUR?
🤦♀️ I need to go back to bed
i appear to be getting the right stuff. USD invoices get ACH and WeChat Pay which I don't know how to even use lol. haven't tested other currencies but I'll assume it works since stuff usually does. sorry to have wasted your time on my silly mistake.
I'm so glad it's not a bug after all because I was planning to spend 30 minutes re-reproducing and filing a detailed bug report to the team 😅
thanks for catching this
thanks again for your help and yeah, I'm glad too cause I was about to be super sad that we can't use the Payment Elements with all the options!
yay 🙂