#devangbhuva97

1 messages Β· Page 1 of 1 (latest)

dense skiffBOT
trail token
#

Can you share the pi_xxx ID you're using in that screenshot?

wicked walrus
#

pi_3M6uaWAjORjIkyJ01m9mdbGs_secret_5RzhChaH2zAQ6yLiA5Dl9AonU

trail token
#

Ok, this is a direct charge created for acct_1JMYI1AjORjIkyJ0 by the controlling platform (acct_1Cbrx8FpU9DlKp7R). In this case, the platform is configured to control which PMs are available to the connected accounts. See: https://stripe.com/docs/connect/automatic-payment-methods?connect-payment-integration-type=payment&connect-charge-type=direct&connect-account-type=standard&on-behalf-of=false#allow-connected-accounts-manage

Increase conversion with automatic payment methods for existing platforms.

wicked walrus
#

Thanks @trail token let me check that things

#

I have couple of doubts on payment element usage as well

  1. Will it work for stripe invoice & stripe subscription api in same way?
trail token
#

Do you mean can you create a Subscription and use the Payment Element to confirm the initial payment (if due)?

wicked walrus
#

Yes

#
  1. How can I make sure that if customer entered same card which already exists, then it won't create duplicate card entry
trail token
trail token
wicked walrus
#

@trail token I directly created pi_3M6v9MAjORjIkyJ004R9WC12_secret_PKnkePvWP8vl9Xe2YyvjTOeoQ new payment intent but it's not showing

wicked walrus
# trail token Yep, Payment Element supports subscription integrations: https://stripe.com/docs...

Looks like our use case totally different here..

We are listing recurring prices (from stripe) & onetime prices (from our system - it means we are not creating onetime price in stripe), so as per our current system, if customer selects recurring prices & onetime prices both in single order, we are creating subscription with additional onetime items without price ids & if customer selects only onetime prices, we are creating invoice

#

Till now we are using Stripe Card Element to collect payment but now we are planning to use Stripe Payment Element to support more payment methods in our checkout

trail token
# wicked walrus Looks like our use case totally different here.. We are listing recurring price...

Sure, that'll still work although your integration would change a little:

#

They'll only appear on the initial invoice, and will be reflected on the initial Payment Intent generated by the invoice. Then you can just confirm the PI as normal with the Payment Element

wicked walrus
#

Ok.. let me try that

trail token
#

What am I checking?

wicked walrus
#

I created new payment intent without connected account but still it's not showing

trail token
wicked walrus
#

Yes.. make sense.. thank you!

trail token
#

np!

wicked walrus
#

Our use case is save the payment method & charge in future. So which option will suitable for us? setup_future_usage or off_session ?

#

& what's different between both?

#

Because read - All other payment method types either don’t support setup_future_usage or only support off_session.

pseudo bough
#

setup_future_usage is how you save a payment method during a payment

#

so for example you use it on the first payment of a subscription, or the first PaymentIntent you create for a customer, so that the payment method they use during that payment gets saved to a Customer object for future usage.

wicked walrus
#

Hey @pseudo bough

pseudo bough
#

hello

wicked walrus
#

Now as per use case, I'm trying to use Payment Intent element with multiple payment methods, how can pass automatic_payment_methods & setup_future_usage options in invoice api?

pseudo bough
#

how can pass automatic_payment_methods
you can't, invoices don't use that feature unfortunately.

wicked walrus
#

It means Stripe Payment Element won't work with Invoice API?

pseudo bough
pseudo bough
wicked walrus
#

But in my account, it's enabled... still it's not showing?

#

& What about setup_future_usage ?

#

How can I collect payment off session in future?

pseudo bough
#

& setup_future_usage options in invoice api
you need to manually update the invoice.payment_intent to set that value on it, after finalizing the invoice

wicked walrus
#

Oh... it's really bad

wicked walrus
pseudo bough
#

I agree! will raise the feedback

pseudo bough
wicked walrus
#

invoice id: in_1M6wmhAjORjIkyJ0blVxPsnv

#

payment intent client secret: pi_3M6wmiAjORjIkyJ00n7LAymB_secret_hy8ZGSkK7m9VBuXtfbGr3BFMA

pseudo bough
#

thanks looking

#

so that invoice is in USD

#

so most methods in your screenshot can't apply since they're EUR only. So it's really only payable with cards. Was there a method you were expecting to see?

wicked walrus
#

ACH Credit Transfer

#

WeChat Pay

pseudo bough
#

not sure about WeChat

wicked walrus
#

I'm facing same issue + another issue in subscription api

  1. Not able to find way to pass all payment methods which enabled
  2. By default it's taking setup usage future enable, how can I change according us
  3. In trail period recurring product, payment intent won't be created. So what to do in that case to show payment element?
wicked walrus
pseudo bough
#
  1. it's the same invoice setting page mentioned above
  2. why would you want to change it? you need to save the payment methods, since it's a subscription, that's why we default it to on for subscription invoices.
    3 use the pending_setup_intent from the Subscription object, with confirmSetup instead.
wicked walrus
#
  1. but some how that's not working
  2. Yes.. that totally make sense
  3. Got it
pseudo bough
#

some how that's not working
what does that mean exactly, what did you expect to see, where, and what did you see instead?

wicked walrus
pseudo bough
#

as for Wechat, I checked and it's because it's only compatible with send_invoice, not charge_automatically (since it involves a redirect to a payment page)

wicked walrus
#

but we don't want to send invoice through email

pseudo bough
#

you don't have to then. Just means WeChat is not an option!

wicked walrus
#

We want to charge through our checkout which is using Payment Element

pseudo bough
#

cool, then you can do that just fine.

#

I explained why other payment methods can't be used(you're charging in USD and most of the other methods are EUR only; and some payment methods are only applicable to the send_invoice mode). Cards are always an option.

wicked walrus
pseudo bough
#

the PaymentElement doesn't support ACH Credit

wicked walrus
#

Oh... my god

#

This is really really complex stuff... even as developer we are not able to get it... how our customer will able to understand πŸ˜„

pseudo bough
#

I agree the one-time invoice integration has a lot of problems!

wicked walrus
#

Now final question of today - will Google Pay & Apple Pay will work in all 3 API with Payment Element?

pseudo bough
#

yes

wicked walrus
#

Payment Intent with setup usage future as well?

#

Because if I pass collection method as send invoice, then I can not update payment intent for setup usage future

pseudo bough
#

yep because send_invoice is not really meant to be used if you need to save the payment method, since every invoice will get sent to the customer for a one time payment individually

#

in any case, yes Google/Apple Pay just work ,there's no issues there

wicked walrus
#

Ok.. thanks for support.. I really appreciate

Now it's my term to prepare POC document for us πŸ˜„