#devangbhuva97
1 messages Β· Page 1 of 1 (latest)
Can you share the pi_xxx ID you're using in that screenshot?
pi_3M6uaWAjORjIkyJ01m9mdbGs_secret_5RzhChaH2zAQ6yLiA5Dl9AonU
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
You can control this behaviour on the Dashboard of the platform: https://dashboard.stripe.com/settings/payment_methods/connected_accounts
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
Thanks @trail token let me check that things
I have couple of doubts on payment element usage as well
- Will it work for stripe invoice & stripe subscription api in same way?
Do you mean can you create a Subscription and use the Payment Element to confirm the initial payment (if due)?
Yes
- How can I make sure that if customer entered same card which already exists, then it won't create duplicate card entry
Yep, Payment Element supports subscription integrations: https://stripe.com/docs/billing/subscriptions/build-subscriptions?ui=elements
We won't automatically de-duplicate cards so you would need to handle that yourself
@trail token I directly created pi_3M6v9MAjORjIkyJ004R9WC12_secret_PKnkePvWP8vl9Xe2YyvjTOeoQ new payment intent but it's not showing
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
Sure, that'll still work although your integration would change a little:
- Create the subscription with the recurring price(s), and use the
add_invoice_itemsparameter to add your one-time prices: https://stripe.com/docs/api/subscriptions/create#create_subscription-add_invoice_items
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
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
Ok.. let me try that
@trail token #1044577798750216242 message
Can you check this?
What am I checking?
I created new payment intent without connected account but still it's not showing
Which specifically are you expecting to see? I suspect its because of setup_future_usage param which a lot of PMs don't support: https://stripe.com/docs/payments/payment-methods/integration-options#additional-api-supportability
Yes.. make sense.. thank you!
np!
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.
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.
Hey @pseudo bough
hello
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?
how can pass automatic_payment_methods
you can't, invoices don't use that feature unfortunately.
It means Stripe Payment Element won't work with Invoice API?
instead they use their own settings from https://dashboard.stripe.com/settings/billing/invoice
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
it does work , it's just that the available payment methods are defined by the settings on that page linked above
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?
& setup_future_usage options in invoice api
you need to manually update theinvoice.payment_intentto set that value on it, after finalizing the invoice
Oh... it's really bad
what about this? anything am I missing?
I agree! will raise the feedback
can you share the invoice or PaymentIntent ID in question?
invoice id: in_1M6wmhAjORjIkyJ0blVxPsnv
payment intent client secret: pi_3M6wmiAjORjIkyJ00n7LAymB_secret_hy8ZGSkK7m9VBuXtfbGr3BFMA
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?
that can't apply since it's charge_automatically
not sure about WeChat
I'm facing same issue + another issue in subscription api
- Not able to find way to pass all payment methods which enabled
- By default it's taking setup usage future enable, how can I change according us
- In trail period recurring product, payment intent won't be created. So what to do in that case to show payment element?
π
- it's the same invoice setting page mentioned above
- 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 thepending_setup_intentfrom the Subscription object, with confirmSetup instead.
- but some how that's not working
- Yes.. that totally make sense
- Got it
some how that's not working
what does that mean exactly, what did you expect to see, where, and what did you see instead?
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)
but we don't want to send invoice through email
you don't have to then. Just means WeChat is not an option!
We want to charge through our checkout which is using Payment Element
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.
as mentioned, it's charge_automatically... that's ACH Credit Transfer option is not available..
But now I make collection method as send invoice.. but still it's not showing
the PaymentElement doesn't support ACH Credit
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 π
I agree the one-time invoice integration has a lot of problems!
Now final question of today - will Google Pay & Apple Pay will work in all 3 API with Payment Element?
yes
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
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
Ok.. thanks for support.. I really appreciate
Now it's my term to prepare POC document for us π