#colin-deferintent-invoice

1 messages · Page 1 of 1 (latest)

trim questBOT
lyric surge
#

@zinc estuary We don't reopen threads but if you have a clear summary and clear follow up question I'm happy to help

zinc estuary
#

yeah we were just in the middle of a discussion and there's a bit of context. #dev-help message

#

The answer to his question is: No. We don't specify so are using automatic payment methods.

lyric surge
#

Discord is busy, we help in real time numerous developers and can't really keep track of past conversations. Please clearly explain the issue all summarized with your question(s) and I will try to help

zinc estuary
#

Gotcha. Ok so I'm having an issue with combining the deferred intent flow with creating one-off invoices. Here is my current flow:

  1. Initialize stripe elements
  2. When user submits form, request client secret from server
  3. Server generates invoice and invoice item and finalizes invoice
  4. Server returns client secret from Payment Intent on the finalized invoice
  5. Client runs confirmPayment with the client secret to process the payment.

Running this flow, I'm getting the following error message:
Payment details were collected through Stripe Elements using automatic payment methods and cannot be confirmed with a Payment Intent configured with payment_method_types.
However, I'm not setting payment method types explicitly so I don't know why it's saying that the Payment Intent is configured with payment_method_types.

lyric surge
#

colin-deferintent-invoice

zinc estuary
#

that's very confusing because we've been using this flow for Subscriptions for some time. I'm just now repurposing the same flow for one off purchases. This is how I'm creating the elements:

const elements = stripe.elements({
    mode: 'payment',
    amount: planAmount,
    currency: 'usd',
    appearance,
})
lyric surge
#

yeah then switch to subscription and it should work

zinc estuary
#

ok so I was on subscription originally and got this error instead:

#

but I don't see where I can specify a value for setup_future_usage when creating an invoice

lyric surge
#

Sorry I'm confused, are you passing setup_future_usage on Elements init? Or no?

zinc estuary
#

I am not

#

this is how I create the elements:

    mode: 'subscription',
    amount: planAmount,
    currency: 'usd',
    appearance,
})```
lyric surge
#

Okay I asked my team and it's apparently just totally unsupported which is... surreal if you ask me

zinc estuary
#

I've never passed that property to anything so you can see where my confusion about that error comes from haha

#

oh. wow lol

lyric surge
#

basically you have to pass payment_method_types explicitly in payment mode

zinc estuary
#

ok so I can't use a subscription mode for one-off payments (that makes sense) but in order to do payment mode I have to explicitly specify payment method types. That's annoying, but also clear enough so I can give that a try.

lyric surge
#

it's only because you use one-time invoices + that defer flow (which is really uncommon honestly)

zinc estuary
#

fascinating. I wasn't the developer who setup the defer flow originally, but from what it sounded like it seems like the defer flow in general is uncommon?

#

Is there something less common about the defer flow + one-time invoices? Just trying to figure out if we should be using a different flow for one-time invoices.

lyric surge
#

the defer flow is only a few months old, not our default integration path (none of our quickstart guide use it) so it's less common. And defer + one-time Invoice is even rarer that's all.
We should fix it, just will take some time

zinc estuary
#

Cool cool cool. Appreciate the insight. Last question: Can you point me to the documentation that lists the possible payment method type strings? The property is unfortunately just typed as string[] and I can't find the valid options anywhere 😢

#

ohhh found it in a different type file!

zinc estuary
#

ah but that's even better. Thanks for all your help!

lyric surge
#

sure thing! Going to push on the product teams to fix this glaring annoyance too :p

zinc estuary
#

haha appreciate it!

#

ok sorry I got a followup before this thread closes... I started looking at doing your normal payment flow (not the defer flow) and I'm not seeing how it would be possible to follow that flow if one wanted to use a specific Price instead of specifying an Amount. Payment Intents don't allow attaching a PriceID so I've gone the approach of creating an invoice, adding an invoice item, and then finalizing the invoice. However, the invoice item create function REQUIRES a customer which wouldn't be available at the time of payment intent creation in the normal payment flow.

lyric surge
#

Yeah Invoicing requires a Customer, no way around it. Really if it were me I'd just set the right amount on a one-time PaymentIntent. I wouldn't use Price(s) at all

zinc estuary
#

yeah it seems like that's the direction the docs push you. But then do you lose any ability to see who's buying which products?

lyric surge
#

Yep you basically build all of this yourself (which I absolutely would in this case, I'd never use Invoicing for this personally)

zinc estuary
#

sorry when you say "build all" do you mean build all of the reporting?

lyric surge
#

yes

zinc estuary
#

jesus

#

ok final (probably) question: is it impossible to accept apple/google payments when specifying the payment_method_type?

#

those aren't listed in the available types

lyric surge
#

those work with card so it will just work

zinc estuary
#

oh fantastic