#tomi
1 messages · Page 1 of 1 (latest)
Hi there 👋 the section of the documentation that you linked to is pretty new, thats our recently released flow for registering domains. It extends beyond Apple Pay.
Previously you had to register the Apple Pay Domain using a live key because Apple Pay always checked against live accounts, even in test mode. So registering a domain in test mode had no effect.
Hey, thanks for your answer! got it, understood on the docs. So, you're saying that now you can register a domain for a test mode connected account? previously, being forced to do it on live mode meant you weren't able to test the Payment Request Button using Direct Charges, so if that's still the case, is there any workaround to test that NOT in prod?
Before (and still I'm pretty sure) you added the domain in live mode so you could run tests in test mode. Does that sound different from the behavior you were seeing?
so, the issue that happened before was the exact same one outlined by this different user in the thread I linked previously: #dev-help message
tl;dr: the process to register a domain for a connected account was to use the Stripe-Account header. However, if you wanted to use a test CA, but had to use the Live API key, then you would get the following error:
"error": { "message": "The account acct_aTestConnectAccount was a test account created with a testmode key, and therefore can only be used with testmode keys.", "type": "invalid_request_error" }
Gotcha, but you said you're not encountering that error now? Did you just create the Payment Method Domain, or did you verify/validate it as well?
I still get that error if I use the Live API key. What I tried was to use the Test API key with the test connected account ID. However, I got the following error (understandable as it is example.com, I don't actually have a domain with the verification file to test it):
{ "id": "pmd_1Nx8E2FsKEzRQU3c57dXmNYL", "object": "payment_method_domain", "apple_pay": { "status": "inactive", "status_details": { "error_message": "We attempted to retrieve the file at https://example.com/.well-known/apple-developer-merchantid-domain-association, but received a 404 status code from your server. Please check that the file is hosted correctly. Note that our servers most likely send different HTTP headers than your browser; you should check your logs to see why the request failed. For more information, see https://stripe.com/docs/payments/payment-methods/pmd-registration." } }, "created": 1696338082, "domain_name": "example.com", "enabled": true, "google_pay": { "status": "active" }, "link": { "status": "active" }, "livemode": false, "paypal": { "status": "active" } }
Hm, honestly I don't recall the state of this. I remember seeing discussion about it recently but don't know where that landed. I'm going to try to track that down and get back to you.
perfect, thank you so much
Apologies for the delay, have a teammate helping look. One possible approach they've found, is to use OAuth to try to make a livemode connection for the Connected Account, so then you can make live requests for it:
https://stripe.com/docs/connect/oauth-standard-accounts
I also found this related message from my teammate on this topic yesterday:
Registering the Payment Method Domain in test mode as you have should be sufficient for Apple/Google Pay to show up on your test site.
I'm going to see if I can reproduce this process, please bear with me a bit longer.
Wait wait wait @floral grotto you're doing Destination Charges? Apologies for overlooking that detail.
We typically recommend using those with Express or Custom Connected Accounts rather than Standard ones, but when working with Destination Charges you don't need to register the domain on the Connected Accounts. Instead you register it on the Platform account, since that's the account that will be processing the payment.
Just finished testing and confirmed that registering an Apple Pay domain in test mode is not sufficient to cause Apple Pay to be offered for test mode payments.
Hey @wooden heart , thanks for the follow up. Just to confirm it's Direct Charges, not Destination.
Thanks for confirming it's not sufficient to do it in test mode. So just to have it clear, the only "workaround" or suggestion would be the OAuth approach you mentioned there?