#mesudev_api

1 messages · Page 1 of 1 (latest)

wispy ledgeBOT
#

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

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

peak valley
#

hi there!

#

how are you accepting payments? Checkout Session, Payment Element, something else?

noble mountain
#

I'm using the custom web workflow using stripe js elements to save a new payment method for web:

const elements = scriptData.stripe.elements(options);
...
const paymentElement = elements.create('payment');
paymentElement.mount('#new-payment-method-data');
...

and in mobile app contexts (flutter), I'm then using the Payment Sheet option of the flutter_stripe community package:

https://docs.page/flutter-stripe/flutter_stripe/sheet#register-for-an-apple-merchant-id

#

so we're currently accepting payments exclusively by creating + authorizing + capturing payment intents via the payment method ID of stored payment methods for created customer

#

s

peak valley
noble mountain
#

Apple Pay already appeared even without me registering payment method domains in my stripe environment

peak valley
#

Apple Pay already appeared even without me registering payment method domains in my stripe environment
that's odd.

noble mountain
#

Yep, connect express

#

this is the flow we've currently implemented in web

peak valley
#

then you are using either destination charges or separate charges and transfers, correct?

#

is so, then only the platform needs to register the domain, not the connected account

noble mountain
#

I would say yes but would like to double-check just to be sure

peak valley
noble mountain
#

ok yes we're using destination charges, as we create our payment intents via transfer_data > destination ...

peak valley
#

correct, for destination charges you don't need to do anything on the connected account for Apple/Google Pay to work

noble mountain
noble mountain
peak valley
#

if you are using the Payment Elemnet, you shouldn't use the Payment Request Button. I only shared that link because it list all the requirements needed for Apple/Google Pay to work.

wispy ledgeBOT
noble mountain
spice heron
#

Hi taking over here as soma has to step away

#

If you're using the Payment Element, then registering a domain and ensuring the wallets are enabled in your Dashboard's payment method settings are enough

noble mountain
#

alrighty

#

ok great thx

#

And I guess you still have to add an apple pay certificate in stripe?

spice heron
#

Basically if you implement ^, you'll probably have less declines

noble mountain
#

I've deployed the apple merchant developer file and verified it successfully, but I've asked your colleague just before if I have to do this:

$stripe->paymentMethodDomains->create
(['domain_name
' => 'example.com']);

too?

spice heron
#

Yep

#

You need that

noble mountain
#

he said, if I'm using destination charges (which we do), I don't have to do that last step listed in the guide you've linked, is that correct ?

#

oh

#

and I have to do that every single time I initiate a new stripe client on my server, or only once?

spice heron
#

You need to register it on your platform account

noble mountain
#

yeh probably he misunderstood me / I misunderstood him there

spice heron
noble mountain
#

ok; where can I verify that has been successfully done?

noble mountain
#

or can I execute it locally with the live key ?

spice heron
#

You can do it locally or just even do it from the dashboard

noble mountain
#

ah so if I have added a payment method domain via Settings > Payments > Payment Method Domains, that corresponds to doing:

$stripe = new \Stripe\StripeClient('sk_test_...');

$stripe->paymentMethodDomains->create
(['domain_name' => 'example.com']);

#

?

spice heron
#

yep

noble mountain
#

ok so guess that's your colleague meant

#

As the example lists a deferred payment, unavailable at the moment our customer stores a new payment method, it's really exclusively to add a new payment method

spice heron
#

The issue is you don't know how much you're going to charge them later?

#

What's the problem exactly?

noble mountain
#

There isn't any payment available at the moment the payment method is stored

#

it is just to store the payment method, no payment related

spice heron
#

That's what the above linked guide does

#

All it does is set up a PM for future use

#

No payment is created

noble mountain
#

yes but it lists a deferred payment with a specified amount in the applePay argument of the stripe js elemens.create('payments',..) call

spice heron
#

Yeah that's just to pass in how much you're going to charge them later

#

It doesn't initiate a charge

noble mountain
#

yes but that's now known at the moment they store their payment method. So you say it's recommended to do so but it's from a logical perspective impossible in our application

#

which is why I'm confused by this step

noble mountain
spice heron
#

Well if it's impossible then you can't do it

#

Simple as that

noble mountain
#

and apple pay payments may fail??

spice heron
#

But you may have a higher decline rate with Apple Pay

#

Yeah

#

For collecting payment method without paying, apple likes to see specific info on how much you're going to charge

noble mountain
spice heron
#

Yep

noble mountain
#

hmm let me think

#

can that value change later on?

spice heron
#

nope

noble mountain
#

well

spice heron
#

Well technically you can pass whatever you want when creating the payment intent

#

But if it doesn't match the deferred payment request, there may be higher decline rate too

#

Hard to say though

#

All this stuff is up to Apple Pay and the underlying Bank

noble mountain
#

bc I've seen companies that registered apple pay methods by charging 1$ then refunding it immediately, just for the registration of the payment method, saying that that was done fro "security measures". But then I guess they did it exactly to relate a value when the payment method is stored. Yet further transactions with apple pay changed later on.

#

I suppose you would advise against that ?

spice heron
#

Yeah can't say whether or not that's allowed

#

I think banks don't like to see that

noble mountain
#

yeah it sounded weird to me too

spice heron
#

ie charging and immediately refunding

noble mountain
#

but guess that's the reason why

#

I mean it makes apple pay less suitable for any business models where paid amounts regularly change (e.g. depend on the provided service)

#

so now I also understand why Uber does not offer Apple Pay

spice heron
#

Yeah unfortunately it's a quirk with apple pay

#

It's kinda hard to set up a payment method for future payments

noble mountain
#

in this case I wonder if it's even a good idea to offer apple pay as a payment method on our platform, as our business model is based on service providers, so values are technically never the same, always depend on the service bookings. Is there any chance that our platform would for example be negatively flagged if the apple pay is rejected on the side of multiple clients?

#

Bc in that case we prefer to not risk it, I guess

spice heron
#

I don't think so, but I can't say for sure. We just help developers with API questions in here. Someone from support would probably be able to answer that better: https://support.stripe.com/contact

Stripe: Help & Support

Find help and support for Stripe. Our support site provides answers on all types of situations, including account information, charges and refunds, and subscriptions information. Get your questions answered and find international support for Stripe.

noble mountain
#

got it

spice heron
#

Google Pay does not have the same issue

#

There's less restrictions with it

noble mountain
#

okay great. And for Google Pay, as per the dashboard, I only have to register the domains, as already done thanks to the Apple Pay domain verification process, so Google Pay is also covered as soon as you did the apple pay domain verification procedure, correct ?

spice heron
#

Yeah

#

Just have to make sure it's enabled in your payment method settings

noble mountain
#

meaning the google pay option should show up in chrome browser when enabled in payment method settings + domain verified

#

correct ?

spice heron
#

And the customer will need to be signed into Google and have a card added to their wallet

#

Then it will show

#

Assuming you're using the Payment Element

noble mountain
#

got it, makes sense

#

then one last question

#

btw this thread will not be automatically deleted, yes?

spice heron
#

It won't be deleted, but we lock + archive them after some inactivity because we maintain a list of open threads to triage

#

You'll still be able to access it to read back over it though after it's locked and archived

noble mountain
#

Here:

https://docs.stripe.com/apple-pay?platform=web#verify-domain

Your docs say:

"Stripe handles Apple merchant validation for you, including creating an Apple Merchant ID and Certificate Signing Request."

I guess by "Apple Merchant ID" and "Certificate Signing Request" here, you mean the Certificate Signing Requests needed to generate an Apple Developer Certificate of type "Merchant ID", correct ?

spice heron
#

Yeah. If only integrating on the web, you don't need to create a apple developer certificate and merchant id yourself through apple. Just follow that guide

noble mountain
#

That would be my next question. As we offer both a web and also a mobile app to our customers, and the stripe dashboard mentions that you need an apple pay (I guess the merchant ID certificate) for your iOS application, I guess that in our case, we have to do both, A) register our domain for apple pay verification for the web, as done, and also B) create a certificate signing request on our own to additionally create a merchant ID apple developer certificate for use in our mobile app, yes? A) and B) will not conflict with each other? Just because of the wording in your docs, saying:

Stripe handles Apple merchant validation for you, including creating an Apple Merchant ID and Certificate Signing Request. Don’t follow the merchant validation process in the Apple Pay documentation.

spice heron
#

Yeah you'll need to do both if you also have a mobile app

#

They shouldn't conflict

noble mountain
#

ok great

noble mountain
#

as discussed

#

thanks so much for your patience and help, excellent support by stripe, as always!