#jarrett-invoice-payment

1 messages · Page 1 of 1 (latest)

cosmic wind
#

hey there, i recall we were speaking yesterday, are you still facing the same challenges or are you modifying your integration?

hardy bough
#

i decided to just finalize invoices. but i want to save the card to the customer when they pay with the payment element

cosmic wind
#

hmm let me see if this is possible

#

Can you share one of your example paid invoices?

#

or payment intents

hardy bough
#

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".

cosmic wind
#

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?

hardy bough
#

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

cosmic wind
#

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

hardy bough
#

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

cosmic wind
#

they are, but you can override it

hardy bough
#

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.

inner forge
#

@hardy bough while I understand, you are definitely trying to shoehorn your flow on top of an API not exactly built for it

hardy bough
#

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.

inner forge
#

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?

hardy bough
#

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.

hardy bough
inner forge
hardy bough
#

it would appear to be

inner forge
#

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

hardy bough
#

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

inner forge
#

that's your bug right?

hardy bough
#

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)
}```
inner forge
#

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

hardy bough
#

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

inner forge
#

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

hardy bough
#

i'd love to use the custom api that allows me to do so much more 😂

inner forge
#

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?

hardy bough
#

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

inner forge
#

no it will error, you have to hardcode them, no way around it

hardy bough
#

how do I know what’s supported?

inner forge
#

Manually reading each docs

#

there's really no other solution

hardy bough
#

that’s less than ideal. is it currency based or are there more limitations than that?

inner forge
#

😅

#

It's currency based, depends on the country of your account, each PaymentMethod has custom requirements and min/max amounts

hardy bough
#

lmao

#

so I basically have to wait for this bug to be fixed

inner forge
#

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

hardy bough
#

Is it really an edge case?

inner forge
#

yes

hardy bough
#

where do I report it?

#

I’m just confused how it’s an edge case when the docs literally say it should do that

inner forge
#

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

hardy bough
#

I appreciate it

#

additionally what’s odd is that sepa debit was included. Is there something special about that vs the others?

inner forge
#

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 😅 )

hardy bough
#

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

inner forge
#

yeah we don't support invoice + Terminal

#

card_present is Terminal only

hardy bough
#

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”.

inner forge
#

you can't use them, they won't work

#

they only work with the Dashboard and you absolutely should not use them

hardy bough
#

👍

hardy bough
#

@inner forge i found a fix

#

explicitly setting payment_method_types to nil

#

🙂

inner forge
#

huh that's even weirder since it's already nil no?

hardy bough
#

i mean not setting it and sending it as nil aren't the same technically

inner forge
#

fair

hardy bough
#

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

inner forge
#

ohhhh

#

duh

#

but still I should have SEPA then and I only get Alipay

#

haaaaaaaaaa I don't like those Dashboard settings 😅

hardy bough
#

is your invoice in EUR?

inner forge
#

🤦‍♀️ I need to go back to bed

hardy bough
#

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.

inner forge
#

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

hardy bough
#

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!

inner forge
#

yay 🙂