#ionu_unexpected

1 messages · Page 1 of 1 (latest)

full joltBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1372965384050835589

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

main jewel
hexed coral
#

Standard Accounts, ya? What kind of charges are you creating?

main jewel
#

yes, these are standard test accounts. We have a main one acct_1PIwu8BERZ9G8bk2 that processes real payments. And has the same issue (not showing for blocking the alipay/wechat)
The charges are through payment elements, and in the backend with normal payment intents, with connected accounts.
Basically our app is handling the display and payments

hexed coral
main jewel
#

well, it should be the Direct charges. But we do not have checkouts or sessions
we use it like this:
\Stripe\Stripe::setApiKey($_ENV['STRIPE_PRIVATE_KEY']);

$this->connectedAccount = 'the stripe connected account id';
$response = \Stripe\PaymentIntent::create(
$createArgs,
[
'idempotency_key' => 'random string',
'stripe_account' => $this->connectedAccount
]
);

where the stripe private key is the main account one.
The user onboards with us, than we just use the key and the connected account id to generate the intent

#

but the issue for me is the display on the stripe elements payment

#

stripeInstance = await loadStripe(paymentProcessorData.value.stripeKey);
stripeElements = stripeInstance.elements(stripeOptions.value);

stripePayment = stripeElements.create('payment', {
layout: {
type: 'tabs',
defaultCollapsed: false,
},
fields: {
billingDetails: 'never',
},
});

        stripePayment.mount(stripeElementsEl.value);

where options are

image.webp
#

payment_method_types are not sent in this case

#

letting stripe decide what payment methods are for display

hexed coral
#

Why? You only want to allow three of them, right?

main jewel
#

well, at this point, yes. In the future we plan to add others

#

and this way, logic like when to show klarna for example is left to strpe

hexed coral
#

In that case, Stripe will look at the Standard Account's Payment Method Configuration, to decide which payment methods it might present. That's how things work with Direct Charges.

#

Essentially, with Direct Charges, your choices are: explicitly set the restrictions on the Payment Intent or Element; or let Stripe choose from whatever that Connected Account has enabled.

main jewel
#

in that checkout link I sent you, this is what it is used
with the restricted payment methods by the main account

image.png image.png
#

the issue is that I do not have the alipay to block it like ach direct debit for example

hexed coral
#

Any new payment method will be default-on, so I don't think this is ever going to work for you the way you want it to, and every time we add a payment method you'll be scrambling to make sure you block it on your account.

Since these are all essentially "opt out", it likely makes a lot more sense to explicitly set what you want to allow, rather than to block what you don't want, by listing your 'enabled' payment_method_types when creating the PaymentIntent.

main jewel
#

and for example if I add to the payment_method_types klarna, and the conditions are not met, it will just not show it ?

#

and in the front I am actually creating a createConfirmationToken that will be used for the payment intent in the background

hexed coral
#

It might show it, but if the customer doesn't use it, they likely won't care that it's there, any more than an Apple user would care about seeing a Google Pay option.

#

If you explicitly set the payment_method_types when you create the Payment Intent, that setting will carry through to the Payment Element and Confirmation Token.

main jewel
#

for example, in my country, the currency is ron. If I let stripe to decide the payment methods available, if the transaction is not in ron, the klarna option will not show
I just tried to force klarna on an euro transaction, I get "Klarna cannot accept payments in (eur) for customers in RO, valid currencies are: ron."

#

I am from romania, if the transaction was in ron, the automatic version would not show klarna option

#

but I understand. Forcing klarna for example on all non off_session payments, will display it, and throw an error if the conditions are not met

hexed coral
#

Let's invert this:

Why are you trying to limit payment methods?

main jewel
#

because we did not had the time to test them. Every method might have their own specific data. We had some issue with revolut pay for example. So we might need to implement some tweaks for registering the payment on our side

#

so we want to implement them step by step

#

to be sure we do not have uncovered situations

hexed coral
#

With Direct Charges, it's always going to use their Payment Method Configuration, not your Platform's, so I don't think you're going to be able to make these changes without also switching to a flow that can accomodate all the payment types.

main jewel
#

yeah, I was afraid of that 🙂

#

I hoped that blocking all the other payment methods from the main pm will cover all the payment methods

#

and it was easier for me to let stripe handle the payment method availability, like for google pay for example

#

because if I force klarna, and I have off_session payments, the payment element will just throw an error, and display nothing

#

this way I need to have the logic done on my side, to add klarna only if the payment is not off_session, and so on

hexed coral
#

In theory if you have all the redirect stuff set up to handle i.e. 3D Secure card payment authorizations, then the other payment methods should "just work".

What was the issue you had before?

main jewel
#

for one, the above issue with klarna display. For revolut pay I do not remember. it was some small thing on the redirect.
But I guess we will need to go with moving the logic on our side, to be sure of the payment methods

#

thank you for your patience

#

and explanations

#

as a side note, the idea of blocking payment methods from the main pm, only to have the connected account with different payment methods makes little sense 🙂

hexed coral
#

It's only true with Direct Charges. Destination Charges would use your PMC.

That said, in nearly all cases, one would want to use Direct Charges with Standard Accounts.

full joltBOT
hexed coral
#

For revolut pay I do not remember. it was some small thing on the redirect.

But it was enough to need to completely change your integration?

main jewel
#

we did not want to include all from the beginning. At this point users asked for google/apple pay, and klarna

#

revolut was something we thought it would work just out of the box

#

the idea with letting stripe decide was actually because of klarna

#

with the restictions on off_Session payments and country/currencies

#

it made more sense to let stripe decide what to show, since showing it in unsupported situations is kind of useless

#

and having the stripe logic in our scripts is not feasable

full joltBOT
main jewel
#

anyway, thank you

foggy bolt
#

👋 Taking over this thread, catching up now

main jewel
#

that is what I did

#

the stripe main account has a payment method that is used by the connected accounts

#

that restricts all the access to all but cards, google/apple pay and klarna

#

but alipay and wechatpay is not inside the main account, only inside the connected one, so I cannot block it

#

this is from inside the connected account.

image.webp image.webp
foggy bolt
#

Could you the Payment Method Configuration ID in text in the first screenshot?

main jewel
#

that is the one in the second screenshot

#

basically the methods come from the main account to which is this connected to

foggy bolt
#

Have you tried using API to update the payment method config on the connected account instead of using Dashboard? You should be able to

main jewel
#

oh, no, I did not

#

I can list them and update

#

thanks

#

great idea

#

a question in here, are payment methods added to the list often ?

#

my concern is that in 3 months they could have new payment methods added

#

I have to go, if you can answer the question above, please do.
I really appreciate the advice

#

Thank you very much, have a nice evening