#vitaly_46135
1 messages ยท Page 1 of 1 (latest)
Hello! We'll be with you shortly. 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.
- vitaly_46135, 40 minutes ago, 13 messages
The summary, payload is still empty even after verification domain was added for connected account.
Hi
It seems you are using an old integration (request button)
I encourage you to use Express Checkout
It's using the latest Google/Apple Pay APIs
Otherwise, could you share with me more details about what you want to achieve exactly by this? what guide are you following exactly ?
stripe.paymentRequest(paymentRequestPayload)
.then((request: any) => {
return request.canMakePayment();
})
.then((payload: any) => {
// payload is empty
})
Yes you're right it is the old integration, but we're trying to use it with connected accounts. My understanding is, with this payload we're trying to get information is applePay available for client canMakePayment = payload && payload.applePay;
How will you accept Apple Pay later from the customer ?
And when you do your tests do you have a valid card added to your wallet ?
The apple pay payment method accepted on Stripe dash. The card is added to wallet, yes. Strange thing is for some connected account it's working and for some is not
So you are missing a domain registred for one of the connect account
Do you have a live endpoint to your Apple pay integration ? and two Connected Account Id: one working and one not.
Do you have a test env ?
It's not active, only production.
Ok just share with me the landing page
url
which I imagine is public
with the two connect account ids
one min
https://www.decanter.com/subscribe/ acct_1FJclhHv3p1z3Hpu
https://escapecollective.com acct_1M6OJbFWeISIt1Kl
the first is not working, the second is working, you can signup and click on subscribe or join (which is subscribe)
Yes the domain is not registred for this Connect Account.
You've created an Account Domain and not a Connect Domain
you need to do the request from your platform on behalf of your Connect account
like you did for acct_1M6OJbFWeISIt1Kl
Did it, here is the result
"apple_pay": {
"status": "active"
},
"created": 1693593908,
"domain_name": "www.decanter.com",
"enabled": true,
...
"id": "pmd_1NlcLAHv3p1z3Hpu9ky9KcMj",
"link": {
"status": "active"
},
"livemode": true,
...
}```
Hi there ๐ jumping in as my teammate needs to step away. I want to make sure I've caught up correclty, you're working on accepting Apple Pay via the Payment Request Button for a Connected Account? And since we're talking about registering domains for Connected Accounts, you're working with Direct Charges as your Connect charge type?
Hi, yes it should be a payment request button, the old integration. And yes, I'm trying to understand why one connected account can accept the Apple pay payments, and other can't.
I've also used the API call to add domain https://stripe.com/docs/payments/payment-methods/pmd-registration?platform=dashboard#register-your-domain-while-using-connect and result you can see above
How do I get from your landing page to seeing the Payment Request Button on your site? Do you have a test account I can use?
This is where you're expecting to see Apple Pay?
This is what we're seeing
In normal case no error should appear
The text of the error message is our own
Sorry, I'm not following. I see Apple Pay on the screen, so this isn't about whether that button renders?
Could you please try to purchase by apple pay?
The issue is not about rendering Apple Pay button. The issue is about ability to pay
The button is rendered by us, clicking on it is no available, because of empty payload for request.canMakePayment()
No, this site is using a live mode key, I cannot do any testing in it as that could lead to real payments.
Ok. If you click on the button nothing happen. Right?
Don't know, didn't do it because this site isn't using testmode keys.
Well, if you click, nothing happened. First, you should see Apple Pay prompt to confirm the payment. Only after that payment will be accepted
Hm, the flow you're describing sounds a little backwards or maybe I'm missing something. Why would you display Apple Pay before checking if it's an available option?
It's by our design. No/Disabled button should be there
Can you please say us why request.canMakePayment(); return null in response?
Is it because of domain verification issue?
@cerulean sleet the @fiery spindle said that www.decanter.com is not registered domain, is it right?
Not easily without being able to see exactly what's happening. canMakePayment should never return a null response, so I want to see what's happening because that doesn't sound right.
@cerulean sleet I agree with you. Can you debug the code?
Can I see a test version of the site that doesn't use a livemode key?
Or can you share the code you're running?
Unfortunately the sandbox doesn't exists for them
@cerulean sleet look at e variable
return o = e, e.canMakePayment() and then })).then((function(e) {
i = e && e.applePay,
What is e there? Is it your instance of a Payment Request if you're calling canMakePayment() from it?
e - it is response from "request.canMakePayment()"
return stripe.paymentRequest(paymentRequestPayload);
})
.then((request: any) => {
paymentRequest = request;
return request.canMakePayment();
})
.then((payload: any) => {
canMakePayment = payload && payload.applePay;
Also from Stripe's object
Ah ha, sorry, I was wrong before, canMakePayment() can result in null if no wallet is available.
But wallet is available! ๐
Clearly we don't think so, so let me ask some clarifying questions.
Are you running the exact same code on the two sites?
Yes!
Okay, we likely aren't looking for a code difference then. It's like either configuration or environmental.
Also, what place can I read about all possibles returning values for canMakePayment() call?
Yes
If you access this page in Safari, do you see a single Apple Pay button near the top of the page (not the one in the row of three buttons, above that)?
https://stripe.com/docs/stripe-js/elements/payment-request-button
Okay, so yes. That confirms your browser is correctly set up for us to detect a card exists in your Apple Pay wallet.
The other website
Also, if I call ApplePaySession.canMakePaymentsWithActiveCard('merchant.www.decanter.com.acct_1FJclhHv3p1z3Hpu.stripe').then((canmakepayment) => {console.log(canmakepayment)}); - it returns me false
If I call ApplePaySession.canMakePaymentsWithActiveCard('merchant.www.decanter.com.stripe').then((canmakepayment) => {console.log(canmakepayment)}); it returns me true
All the difference in connected account acct_1FJclhHv3p1z3Hpu
Hm, nothing is standing out to me, everything seems to be in place.
Right. We don't understand either
Asking a teammate to take a look
Super! Thank you!
I didn't readily spot any, but didn't look super close either. Is any part of what is showing Apple Pay in your site iframed?
All stuff is doing on top level domain. We communicate via postmessages
The Apple Pay button is rendered into iframe
Type of integration is identical for both connected accounts(working and not)
ApplePaySession.canMakePaymentsWithActiveCard('merchant.www.decanter.com.acct_1FJclhHv3p1z3Hpu.stripe').then((canmakepayment) => {console.log(canmakepayment)}); - false
ApplePaySession.canMakePaymentsWithActiveCard('merchant.escapecollective.com.acct_1M6OJbFWeISIt1Kl.stripe').then((canmakepayment) => {console.log(canmakepayment)}); - true
Are you there?)
Just wondering
Yup, still no clue, still have teammates looking
Will awaiting for your response
A little addition from my side the decanter is connected to US account and escapecollective to AU. They use different keys
Different Platform accounts?
Yes, we have 4 accounts for US, AP, AU and EU. And the connected accounts (clients) according to region
Here https://dashboard.stripe.com/dashboard on top left corner we have dropdown with 4 accounts
Can you share those 4 account ids? I'm opening a new window to step through all of this fresh and look for any differences.
I'm sorry but how can i get the Ids? From Developer menu?
I normally grab them from the top right corner of this page:
https://dashboard.stripe.com/settings/account
Ah thank you, US acct_1LVySpCF6Y3bmA7r
AP acct_1MBab6AkqSlkYWt0
EU acct_1M6shCCJYAlz7GWa
AU acct_1MAZKsLtTyDQobVY
What version of Safari are you using for testing?
Version 16.6 (18615.3.12.11.2)
mine is Version 17.0 (19616.1.27.211.1)
Are you seeing the same behavior? Because I do think I see the modal being rendered as an iframe from a different domain (unless I'm misreading things), and Safari only supports that in version 17+ and requires verifying both domains.
Yes, everything is the same to me, i see the same error on Safari 17
We aware about 3rd party domains and Apple pay, that is why we run stripe on verified domain, then we use postmessages to send events to our iframe
Do you have a login I can use for escapecollective? So I can compare that?
Is the decanter site the first time you're facing this problem? And is it the first to use your modal iframe rather than inline iframe? Grasping at straws here looking for any difference.
As far as I know we have the other clients which claiming about this issue. Some of them in modal iframe. Also, locally, we do test for modal iframe
No, we have clients which facing the issues with apple pay and along with it the clients for whom everything is ok
Any sort of pattern in occurrences?
Like only accounts connected to a speicifc platform, only accounts created after a certain date, etc?
for example https://subscribe.blazemedia.com acct_1Nq0qLFLSashgr74 working fine
and this is connected to US account
Hm, interestingly, that page isn't throwing the same stripe.js error I saw on decanter:
IntegrationError: Stripe.js requires that your page has a <body> element.
Though I'm not certain that's related, but it's at least a difference
I also see these on decanter:
Unable to post message to https://buy.tinypass.com. Recipient has origin https://www.decanter.com.
Is that indicative the postmessage approach you're trying to use isn't working?
Also here is another client from US https://www.sltrib.com/subscriptions/ acct_1Fm47xJGN31AAqYE. which is not working
@cerulean sleet no. It's just indicates that we have different origins
We always receive postmessages
Hm, didn't see those same errors on blazemedia
request.canMakePayment(); returns null. This is the issue for us
I think we're just spinning our wheels here. Can you standup a minimal reproduction showing that behavior, with non-minimized code?
Using testmode keys so we can step through the whole thing.
Locally it is working well
Maybe we could have a meeting to look it on production together?
I'd rather not do this in production, the minimized code is incredibly hard to follow
Minimized code - is hell. Sometimes I work with it ๐
But I also don't think we're going to make any meaningful progress here in this thread and need to spin this into a support ticket.
Also, I have another question. Decanter previously was not connected. Used just keys. All was working well. Then they started to use connected account. Do they need to re-validate domain for new account?
What if for previously integrated with Stripe publishers they need to re-validate domain for connected accounts?
Can you elaborate on what exactly that means, how did that impact the decanter site, what changes did you make?
Also, for future reference, if you made a change and then saw something break, that is useful to tell us up front
You might open decater site and in the console execute this: ApplePaySession.canMakePaymentsWithActiveCard('merchant.www.decanter.com.stripe').then((canmakepayment) => {console.log(canmakepayment)}); this will be true
But if you execute this: ApplePaySession.canMakePaymentsWithActiveCard('merchant.www.decanter.com.acct_1FJclhHv3p1z3Hpu.stripe').then((canmakepayment) => {console.log(canmakepayment)}); it will be false
All the difference in the connected account
Sorry, I don't recognize those commands offhand, where did you get them from, what are they doing?
@cerulean sleet we've opened a support ticket before and also had conversations via email, decanter is also involved.
@cerulean sleet it's general function which is accessible in window object. Documentation here: https://developer.apple.com/documentation/apple_pay_on_the_web/applepaysession/1778000-canmakepaymentswithactivecard
All payment providers doing check using this function to check if payment is available
Also if you need to debug, I can deploy sandbox, but probably on monday
Yes please, a minimal reproduction running with a testmode key would be helpful as we'd be able to step through the whole thing. Do you still have a support case open for this? It's going to need one at this point.
Let me check, probably it should be somewhere in email
Hm couldn't find the ticket
ah might be this > For additional reference, you may provide this case ID: 10107842.
Mm, I'm not sure how to check the state of cases from your end, but don't think that one is open anymore.
@cerulean sleet probably we can create a new one and continue?
Yeah likely, I do have one explicit question before we do that. You mentioned you changed the decanter site, and then saw the issue arise, what specifc changes did you make to your site and integration at that point?
Yeah let me explain
This is how we use init stripe ``` let apiKey = postMessageParams.params.apiKey;
let accountId = postMessageParams.params.accountId;
if (stripe === null) {
if (accountId) {
stripe = window.Stripe(apiKey, {stripeAccount: accountId});
} else {
stripe = window.Stripe(apiKey);
}
}
Decanter first was implemented through direct keys pub/secret and we decided to move them to use connected accounts.
Can you elaborate further? I'm looking for specific changes. If the site broke after those changes, I think those changes are the first thing we should have scrutinized.
Is decanter the only site that went through that migration, or did other impacted sites also go through it?
other impacted sites also go through it.
Hm, starting to sound like a pattern
But! Not all of them got broken
Aanndd I'm back to having no clue
Let's summarize our conversation. The reason of our issue is not trivial and not easy to debug now. We need write email to Stripe's support and continue conversation there. All is fine with configuration from your point
Let's move this to a ticket.
If you can work on standing up a minimal repro and sharing that (along with any credentials we would need to step through that), that will go a long way.
Additionally any other relevant details that we should be aware of (like knowing this broke after changes were made to your site)
If you can detail the changes that you made to your site and integration before this broke, that would also be helpful for us to be able to clearly understand.
You can use this form for that:
https://support.stripe.com/contact/email?topic=api_integration
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.