#TLShadow
spice breach
short quest
hi!
i have been ushing publishable plattform key + connected account id
are you also using the Secret key of the platform + connected account ID on the backend when you create the PaymentIntent?
ancient fulcrum
yes on the backend i use secret + accountId
gonna double check real quick but we do have the whitelabel solution working which i copied 1:1 and just added retrival and return of intent.client_secret
i can provide an paymentent intent and the account id if it helps
short quest
it would yep!
ancient fulcrum
client_secret:
pi_3LnKvNA7Jdode1qs0ILC7KIm_secret_L0iQ32J0VWl0lBXBLKk2svJRG
account :
acct_1LZM2UPGCSjYY4in
intent:
pi_3LnKvNA7Jdode1qs0ILC7KIm
short quest
hmm. That PaymentIntent was not created on that account
that PaymentIntent was also part of a CheckoutSession, which means it makes no sense to try to use that PaymentIntent on the frontend using its client_secret, so I don't know what you're doing there.
ancient fulcrum
oh .. so stripe js can't work with checkout sessions ?
short quest
hmm. That PaymentIntent was **not** created on that account
if you have code that looks like it should be doing that, then most likely the problem is you use a variable for stripe_account like stripe_account => $account and that variable is null, so you need to debug that.
short quest
oh .. so stripe js can't work with checkout sessions ?
hmm, I mean not really? Checkout is a hosted page. You simply get the url from the CheckoutSession and redirect the customer to that page. We have a redirectoCheckout function in stripe.js you could use too but you usually don't need to, and it oeosn't use the PaymentIntent client_secret or anything.
https://stripe.com/docs/payments/accept-a-payment?platform=web&ui=checkout#redirect-customers
ancient fulcrum
i know we are using this process ... and we weant to offer inline payment ... which would require the use of stripe JS .. though i was not aware i have to completly remodel the backend to use payment intent instead of sessions
i was more or less hoping i could retreive the intent from the session
short quest
i have to completly remodel the backend to use payment intent instead of sessions
you do, yes, it's a completely different integration
i was more or less hoping i could retreive the intent from the session
I see where you're coming from, but it doesn't work that way
ancient fulcrum
ok at least thats a clear answer on that topic 🙂 thanks alot
ancient fulcrum
uhm sorry though the since the intent is created with the plattform account and only has transfer data and on behalf of .. it is probably not "owned" by the conencted account ? i just changed to payment intent, and still get the same error
id:
pi_3LnLSlA7Jdode1qs0zMQuJ3H
earnest nymph
Hi! I'm taking over this thread.
ancient fulcrum
hi ... ok never mind i found out you can use conencted account as second parameter on the php account .. which works for the payment intent just need to check wether fees and everything still works as excepted 🙂
earnest nymph
The PaymentIntent you shared is using transfer_data, so it's a Destination Charge. In this case the PaymentIntent belongs to the platform account:https://stripe.com/docs/connect/destination-charges
If you want the PaymentIntent directly on the connected account, then you want to use a Direct Charge instead: https://stripe.com/docs/connect/direct-charges
ancient fulcrum
yeah .. been there .. this had alot of other complications, i have to lookup which one exactly but direct charge was kinda of the chart
so i guess i have no way to access the payment intent without sending the account private key to all the clients ? or i have to see that i get direct charges to work
earnest nymph
so i guess i have no way to access the payment intent without sending the account private key to all the clients ?
I'm not sure I understand this part. What exactly are you trying to achieve?
ancient fulcrum
ok this needs a bit more explanation
we are creating a payment gateway plugin for a shop (woo), to protected the api keys we created a backend to handle the payment. which is using checkout sessions.
now one feature request is to implement inline payment (askin card details on the shop site) .. which would either require our backend to handle the data and thus add PCI compliance as requirement, or we can use the payment flow in the stripe.js flow ... which kinda requires direct charges to work.
though as mentions direct charges had other problems with the application fee or something i can't quite recall anymore. and some further changes on the backend.
and currently i'm testing to get stripe JS working with the system and which problems i ran into to see weather it is feasble and or what amount of work is required
earnest nymph
I don't understand the full context, but you can use Destination Charge for "inline payments".
- Create the PaymentIntent on the backend with the platform secret API key and the
transfer_dataparameter - Then on the frontend use the platform publishable API key to collect the payment information and confirm the PaymentIntent
In this case ( Destination Charge) everything is managed by the platform account
ancient fulcrum
ok thats what i did .. i created a payment intent using transfer_data and on behalf of
and passed client secret to the frontend .. but then i received an error that the payment intent would not be connected to given account because it is owned by the plattform and not the connected account
oh wait .. you mean on the frontend i don't need to pass the conencted account
because i used public key + account id in the test
ahhh okay ... yeah was cought in the middle .. seems to work only with public key
earnest nymph
Awesome!
ancient fulcrum
wasn't aware this is possible since all examples used the private key .. which was a red flag for me
earnest nymph
What do you mean? The secret key (sk_xxx) should be only used on the backend.
When confirming the PaymentIntent on the frontend you should use the publishable key (pk_xxx).
ancient fulcrum
thats exactly what i mean