#kory_best-practices

1 messages · Page 1 of 1 (latest)

subtle muskBOT
#

👋 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/1443416257075613839

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

marsh shell
#

Hi! Looking into your query! Give us a moment.

karmic marlin
#

👋 I would recommends against re-implementing Android SDK in Qt

#

that means you needs to prove on a stricter requirements for PCI DSS. You don't want to do that

#

It's better to just use our SDK, but while you are in an unsupported language, the safer approach would be open a webview and use our provided web component like Payment Elements

rapid bough
karmic marlin
#

Would need to review the calling section to tell

#

And yes I agree maintaining a bridge is toilsome

#

I would recommend webview, easier

rapid bough
karmic marlin
#

Yes. Basically the webview becoming the client. You will have the server anyway

#

Server can be Go/Python/Ruby/Java/.Net etc...

rapid bough
#

I'll spend some time today than trying to test the front-end part out and report back

rapid bough
#

For the most basic test with no server, is this sufficient?

I suppose with server the backend would have to send the client_secret to the front-end and Qt has good networking modules like supports Restful APIs

#

The WebView exists in QML (front-end UI logic), there's also typically a C++ business logic layer that actually talks to backend and the QML

Just trying to test the WebView

drifting adder
#

Hi @rapid bough I'm also an engineer from Stripe. Let me follow up on your question

#

Based on the screenshots that you shared earlier. I believe you are embedding a Stripe-hosted checkout page in your embedded webview, am I right?

rapid bough
#

I've created a payment link in Stripe test account and used that in the WebView as shown in screenshot 2 (the code at least). It's running on Android

drifting adder
#

Ok, payment link is a no-code solution and it will automatically create a checkout session when your customer opens the payment link URL,

#

There's no backend invovled here.

rapid bough
#

I see, does this at least prove the WebView is viable as a client?

What would the next step be if we wanted to involve a backend?

drifting adder
rapid bough
#

I see, would you advise the "Web" -> "Stripe-hosted page" option specifically for this scenario?

#

I suppose I should provide additional context into the end-goal

#

Funds to flow from dance student -> dance teacher. My platform takes a percentage cut. Stripe takes a cut. Refund period built-in (Using authorization and capture perhaps). Cross-border payouts.

Think this falls under "Stripe Standard Connect with Direct Charge"

rapid bough
#

I'm not too sure about the step-by-step flow / process of how Stripe works from technical standpoint in this case but if that's it then at least I'm understanding it now

drifting adder
#

Ok, so basically you want to create a Connect charge and take a cut from the fees that your customer pays

#

https://docs.stripe.com/connect/charges#types First you'll want to decide whether to create a direct charge (i.e., Your connected accounts transact directly with their customers, who are often unaware of your platform’s existence), or destination charge (funds moved to platform first and then transferred to the connected account)

#

Both charge types support application fee so that you can take a percentage cut from the transaction amount.

karmic marlin
#

👋 taking over here and (hello again) and LMK if you need further assistance