#csrn_connect-paypal-checkout
1 messages Β· Page 1 of 1 (latest)
π 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/1367160868688756817
π 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.
- csrn_best-practices, 1 day ago, 15 messages
- csrn_code, 5 days ago, 14 messages
Can you share the request id where you made a charge with the trigger card so I can take a look?
Hi! Will do...
I made the charge indirectly through my local setup. I am struggling to find the request id in the new workbench feature. Is the py_XYZ id sufficient?
Yeah the py id will work
Ah that's a regular destination charge
You need to either make a direct charge or destination + on_behalf_of
For the trigger actions to work, you must use these cards with a Connect charge by setting on_behalf_of, or creating the charge directly on the connected account.
Ah, thank you! This means I probably should add the on_behalf_of property because I did not touch the production code yet.
Yes you'll need on_behalf_of for this to work
I will test it within the next few minutes.
Yes, this worked! Thanks a lot!
The documentation is telling me that on_behalf_of will provide sellers information to the customer? Like registered phone numbers? Can I avoid such a behavior?
https://docs.stripe.com/connect/destination-charges?platform=web&ui=stripe-hosted&destination-or-on-behalf-of=on-behalf-of#:~:text=On-,behalf,-of
Hi π
I'm stepping in as my colleague needs to go
Hi @polar chasm ! Thank you @cyan stone !
On Behalf Of determines which account is considered the Merchant of Record.
This means that account's information is what will be presented to the Customer
Can the merchant configure to not publish? Or is it mandatory automatically? Otherwise, I would have to remove on_behalf_of again because our merchants are quite privacy sensitive.
This is required. The Customer needs to be able to identify a merchant that is accountable for things like disputes
If your Connected Accounts are not willing to share this information with the Customers then you will likely need to not use On Behalf Of and instead use regular Destination Charges, where your Platform is the merchant of record
Alright... Thank you very much for the helpful information. A last question about this I remember vaguely. Destination charges with on_behalf_of would be required to enable paypal payments via stripe in Germany, right?
This would be a topic to discuss with our team then.
Where is your Platform Account based?
Germany
I am currently adding payment_intent_data only on one-time payments (mode: 'payment') when creating a new checkout session. With subscriptions (mode: 'subscription'), I am doing nothing to indicate a destination charge which probably means these are direct charges.
Okay so you are using Checkout Sessions. Can you share some example request IDs for both payment and subscription scenarios?
They will start with req_
Here's how you can find a request ID: https://support.stripe.com/questions/finding-the-id-for-an-api-request
req_kufNTVWrHyOJkJ
This is a one-time payment I made following the on_behalf_of adjustment.
And this is from a subscription (setup_intent?): req_gyjggKmZfPe03i
This is just a setup intent. It has no relationship to a Checkout Session and is being made directly on the Platform
POST to /v1/subscriptions req_SGL48iYDzeFg1c
I don't see a second checkout session in the sandbox logs.
Okay so the Subscription is being created using normal Destination Charges with the Platform as the merchant of record
Then this would not qualify for PayPal use but the one-time payments would potentially be fine.
Sorry, I misread your answer. Those were destination charges.
This means in both cases PayPal would be possible to offer when not using on_behalf_of with one-time payments. Is this correct?
That is my read but I haven't tested it. You should be able to test this scenario pretty quickly
It's switched on in my sandbox with info ("requires approval") although it does not show up on the Stripe-hosted checkout page (checkout.stripe.com).
That sounds like it's not enabled yet (since it "requires approval"). Can you share the Checkout session ID where it does not appear?
req_eUXR7HP5o2BhkY
You are specifying the Payment Method Types in your API requests:
payment_method_types: {
0: "card",
1: "sepa_debit",
2: "giropay",
},
That was stupid of me. You are right π
Sorry
There are more things to do to get this up and running. But it looks like it's doable.
Great. I'm glad that's working for you
Thank you very much for your support! I wish you all the best. π
Happy to help π It's why we're here.
Could it be that there is no "onboarding request to PayPal" in Sandbox mode?
I do not see the "settlement preference" where I would continue with the configuration after turning PayPal on.
I don't think that is required while in a Sandbox (test mode) account based on this language in our doc
When youβre ready to go live, follow the steps to activate PayPal payments.
Okay, I will postpone this issue. Thanks again, and have a nice day π Bye!
You too π