[help needed] unable to connect to real device NFC (tap to pay)

TatsuUkraine commented 1 year ago

Summary

I have been trying to test Tap to Pay integration on real device (simulated: false) and each time I'm trying to connect to the NFC SDK fails with Unauthorized Network exception. Just want to check if it's known limitation or maybe we have problems in our integration.

Code to reproduce

iOS version

16.5

Installation method

Documentation

SDK version

2.21.0

Other information

App is signed with development certificate
Apple granted access to Tap to Pay (entitlements and identifier configured according to docs)
Stripe integration on backend is in sandbox mode
Connection using local mobile method works with simulated: true flag
BT connection works with any simulated flag
I did debug of HTTP requests in the app, response comes from armada.stripe.com

bric-stripe commented 1 year ago

Just want to check if it's known limitation or maybe we have problems in our integration

doesn't sound like an integration issue but its also not a known issue that I'm aware of.

can you provide the account id of the account (acct_.......) you're trying to use and the location id (tml_.......)? This will help us hopefully track down some logging to debug.

TatsuUkraine commented 1 year ago

@bric-stripe sure, do you need account ID of the connected Stripe account? Or main Stripe account? If it helps I can also provide HTTP payload that stripe sdk generates when armada domain replies with Unauthorized error

TatsuUkraine commented 1 year ago

If there is any security issues with sharing payload I can find and share just the request ID or anything like that

bric-stripe commented 1 year ago

do you need account ID of the connected Stripe account? Or main Stripe account?

it would depend on the type of connect platform being used. But whichever is in the Stripe-Account in the request header should be the one we need.

I can find and share just the request ID or anything like that

ah, excellent. In the request body should be a device_uuid. Can you share that and the Request-Id?

TatsuUkraine commented 1 year ago

sure, give me a few min

TatsuUkraine commented 1 year ago

Account id acct_15p0WAJUdU9aPVAL device_uuid: 47FDE319-CB65-457A-A106-44C42472A038

Response:

{
  "request_id": "1688166220505",
  "rpc_error_code": "RPC_ERROR",
  "app_error_code": "UNAUTHORIZED",
  "error": "An error occurred, applicationEC: UNAUTHORIZED, errorDetails: []",
  "content": ""
}

bric-stripe commented 1 year ago

thanks for providing all that.

I found the error on the server side:

Merchant ID does not belong to platform

we should be providing a better error message for this situation, but can you double check the account id's? Since this is being run in test mode make sure the connected account id you're using in onBehalfOf shows up as a connected account in the dashboard when toggled in to test mode since the two environments don't mix.

TatsuUkraine commented 1 year ago

Not sure that I understood what issue is. So the account ID that I provided is the ID of our main Stripe account. BehalfOf that I'm proving during the connection - is the account ID of the client's Stripe account. Am I providing wrong data to sdk and it's causing this error?

P.s All works fine with Simulated Tap to Pay connection

TatsuUkraine commented 1 year ago

So the account ID that I provided is the ID of our main Stripe account

This ID I took from the request headers

bric-stripe commented 1 year ago

the account ID of the client's Stripe account. Am I providing wrong data to sdk and it's causing this error?

this all sounds correct but can you confirm when you log in to the dashboard with the platform account and switch to "test mode" that that client stripe account id you're using shows as a test mode account for the platform? Since you're trying to connect in test mode the onBehalfOf account id must be a test mode account id for the main platform account. So checking in the dashboard is just a way to confirm it's registered as a test mode account id and not a production account id since the two environment's don't mix.

TatsuUkraine commented 1 year ago

yes, I see this connected account ID under the Connect section in test mode of main Stripe account. It has acct_1KRuICBtOYQR2TL5 ID

TatsuUkraine commented 1 year ago

if I understand you correctly)

TatsuUkraine commented 1 year ago

hm, I just figured out one strange thing. When I connected acct_1KRuICBtOYQR2TL5 account, Tap to Pay connection fails with Unauthorized error. But when during the Stripe connection I create dummy account (in test mode) - SDK connects just fine

bric-stripe commented 1 year ago

OK, thanks for confirming. I realized I may have missed one other thing to check. If using direct charges the Stripe-Account header needs to be set to the connected account's id when creating the connection token. Some more info here: https://stripe.com/docs/terminal/features/connect#direct-connection-tokens I confirmed if that and the onBehalfOf aren't both being set to the same accountid you can also get that error message.

for the new account that worked, is it the same "type" of connected account? The type being one of standard, express, or custom.

TatsuUkraine commented 1 year ago

onBehalfOf account id must be a test mode account id

ok I think I got it) sorry) so acct_1KRuICBtOYQR2TL5 is the account that I created on my own for testing purposes and then connected to our main account. Another account that doesn't have this issue (acct_1NOrIGAVSIN3qYGu) I created during the connection in test mode. Also the difference between them is that on Dashboard the second one has alert This is a test account created by ***, while the first one doesn't

for the new account that worked, is it the same "type" of connected account?

both has standard

TatsuUkraine commented 1 year ago

If using direct charges the Stripe-Account header needs to be set to the connected account's id when creating the connection token. Some more info here: https://stripe.com/docs/terminal/features/connect#direct-connection-tokens I confirmed if that and the onBehalfOf aren't both being set to the same accountid you can also get that error message.

need to double check, but it could be the case actually. I will verify this on Monday

TatsuUkraine commented 1 year ago

thank you for your help! I will do some checks on Monday and will come back with the findings)

TatsuUkraine commented 1 year ago

Hi, so I double checked our backend integration. Catch here that we using destination payments with on behalf of. So we generating connection token based on the this docs https://stripe.com/docs/terminal/features/connect#destination-connection-tokens And connecting to the Tap to Pay reader based on this documentation https://stripe.com/docs/terminal/payments/connect-reader?terminal-sdk-platform=ios&reader-type=tap-to-pay#connect-reader

If you use destination with on_behalf_of, you must also provide the connected account ID in SCPLocalMobileConnectionConfiguration

TatsuUkraine commented 1 year ago

One more note. When I'm using connection token generation for direct payments, I can connect using both stripe account IDs. With destination connection tokens - connection fails for acct_1KRuICBtOYQR2TL5, but it works for acct_1NOrIGAVSIN3qYGu (sandbox generated during the linking to main account)

bric-stripe commented 1 year ago

With destination connection tokens - connection fails for acct_1KRuICBtOYQR2TL5, but it works for acct_1NOrIGAVSIN3qYGu (sandbox generated during the linking to main account)

Could you try connecting to acct_1KRuICBtOYQR2TL5 using a live mode connection token? I suspect that account may not be able to be used in test mode if it's associated with the platform account in live mode. If that's the case you'd need to use the test mode only connect accounts for testing.

TatsuUkraine commented 1 year ago

Unfortunately this account is for testing only and it doesn't have all necessary info to be activated and accept CC payments( so I can't use it in live mode

TatsuUkraine commented 1 year ago

One point to note. When I connect this account in test mode to a platform account all other payments and connections working fine. I can connect to BT devices for instance and accept CC payments with them. At that point only Tap to Pay on iOS can't be connected. On Android all works fine with the same account

TatsuUkraine commented 1 year ago

If I'm not providing onBehalfOf during the connection to iOS tap to pay, it connects, but collectPayment doesn't work. It fails with the error that required param is missing (can't remember exactly wording)

bric-stripe commented 1 year ago

When I connect this account in test mode to a platform account all other payments and connections working fine

OK, something sounds off then. Let me bring this to the backend team to see if they can make sense of why that account combination is hitting that "Merchant ID does not belong to platform" error. If it's working for Bluetooth payments in test mode it should work with tap to pay as well.

It fails with the error that required param is missing (can't remember exactly wording)

I suspect it may have been SCPErrorInvalidRequiredParameter which would happen if the PaymentIntent was created with an on behalf of value that didn't match the connect configurations on behalf of. This would be because the on behalf of values need to match but since you can't connect when using that account id it sounds like there's a bug somewhere that we'll need to dig in to.

TatsuUkraine commented 1 year ago

So just to sumorize so you could have entire picture. We using destination payments. When we creating Payment intent on backend we creating it with onBehalfOf property. I can connect to BT devices, process payments on both platforms on any of these 2 accounts that I shared before.

When it comes to Tap to Pay. I can do the same on Android without any issues (both real and simulated). With iOS I can connect and collect payment with acct_1NOrIGAVSIN3qYGu.

With account acct_1KRuICBtOYQR2TL5 I can't connect to tap to pay real device (but I can to simulated) if I provide onBehalfOf in SCPLocalMobileConnectionConfiguration. If don't provide onBehalfOf I can connect to real Tap to Pay hardware, but I can't collect payment

TatsuUkraine commented 1 year ago

At that point this unclear situation around Tap to Pay on iOS hold us from delivering this feature to our customers, because it's unclear if it's going to work in live mode for all out stripe users) I hope you can help me out with understanding if it's test mode specific or we doing something wrong with our integration)

Really appreciate your help!)

matthewryan commented 1 year ago

FWIW I started integrating Tap to Pay on iPhone today and am also seeing this issue, more or less the same setup and steps as @TatsuUkraine. Thanks for looking into this @bric-stripe - let me know if I can provide any debug info as well.

bric-stripe commented 1 year ago

sorry for delay. I'm pretty confident integration is setup correctly but I'm trying to get confirmation from server side teams that this is a test-mode issue with that specific account, acct_1KRuICBtOYQR2TL5. Since it works with the testmode only account, acct_1NOrIGAVSIN3qYGu, things on the SDK and integration side seem to be working as expected. But I'd like to understand why acct_1KRuICBtOYQR2TL5 is having trouble so checking with some other folks on that.

bric-stripe commented 1 year ago

@matthewryan could you provide account id's as well? Having another sample would be great to help debug this. Also to confirm a few things:

you're only seeing this is testmode, correct?
are you able to test if its working in livemode?
have you tried creating a new connected account in testmode only to confirm that also works for your situation?

matthewryan commented 1 year ago

I appear to be getting the same error in livemode too @bric-stripe. I will create a new connected account shortly.

One point of interest that might be relevant is that our root account acct_14P3GIDGO95FH5Z4 is based in Australia where Tap to Pay on iPhone isn't yet available, but the connected accounts are located in the US, 🤞 that's OK.

attempted a livemode connection to acct_1LAMWEDGHu3zla9Q which is a US account and see a 9040 error:

2023-07-06 11:58:13.721810+1000 Vintner[10260:621047] [StripeTerminal] e scope=SCPTerminal event=connectReader logpoint_level=info account=acct_14P3GIDGO95FH5Z4 app_id=com.withwine.vintner error=A_network_error_occurred error_code=9040 error_domain=com.stripe-terminal exception=NETWORK_ERROR.InternalNetworkError last_request_id=req_0kVwyZeWQgizQy reader=tmr_FKLbSQ7qsHmAu2 sdk_version=2.22.0 time=1688608693720 total_time_ms=1108
2023-07-06 11:58:13.726656+1000 Vintner[10260:621047] [StripeTerminal] x scope=scpterminal event=connectreader domain=terminal_request outcome=error_code_9040 time=1688608693726

attempted a testmode connection to acct_1MgzP3D1txHMccyl a US located test account and also see the 9040 error:

2023-07-05 19:04:23.254856-0700 Vintner[10327:628238] [StripeTerminal] l scope=SCPAppleBuiltInReaderPrepareOp event=unexpected_state logpoint_level=warning account=acct_14P3GIDGO95FH5Z4 app_id=com.withwine.vintner error=Network_error error_code=9 error_domain=SCPAppleBuiltInReaderErrorDomain error_variant_name=NetworkError last_request_id=req_uUh542sU8rpNrW reader=tmr_FKLkfQjWnPMeuD sdk_version=2.22.0 time=1688609063246
2023-07-05 19:04:23.261030-0700 Vintner[10327:628238] [StripeTerminal] t scope=SCPTerminal event=state_change logpoint_level=info account=acct_14P3GIDGO95FH5Z4 app_id=com.withwine.vintner command_in_progress=discoverReaders last_request_id=req_uUh542sU8rpNrW reader=tmr_FKLkfQjWnPMeuD sdk_version=2.22.0 time=1688609063257
2023-07-05 19:04:23.263343-0700 Vintner[10327:628238] [StripeTerminal] e scope=SCPTerminal event=connectReader logpoint_level=info account=acct_14P3GIDGO95FH5Z4 app_id=com.withwine.vintner error=A_network_error_occurred error_code=9040 error_domain=com.stripe-terminal exception=NETWORK_ERROR.InternalNetworkError last_request_id=req_uUh542sU8rpNrW reader=tmr_FKLkfQjWnPMeuD sdk_version=2.22.0 time=1688609063262 total_time_ms=3866
2023-07-05 19:04:23.267822-0700 Vintner[10327:628238] [StripeTerminal] x scope=scpterminal event=connectreader domain=terminal_request outcome=error_code_9040 time=1688609063268

iOS device region is set to the US and simulated location is San Francisco which appears to negate the geolocation restrictions for other US-only readers (ie. I am able to test the implementation of the M2 reader just fine from here in Sydney).

bric-stripe commented 1 year ago

@matthewryan looked in to your logs a little more and you're hitting a different error so we should move this to a separate issue. From the Stripe side the reader setup is succeeding but when the SDK requests the ProximityCardReader.prepare the ProximityCardReader is returning a .networkError. I assume the device can communicate with Apple's server's without issue? No firewall setup or anything like that? Assuming so I'll need to check with some folks to see if there are additional details we can get from that error.

TatsuUkraine commented 1 year ago

@bric-stripe so today I was able to test tap to pay with live mode account, and I see exactly the same issue as with test mode with a different account

TatsuUkraine commented 1 year ago

Device uuid: AA447B57-ACB6-4BB9-980A-BA944752299F Response

{
  "request_id": "1688659578859",
  "rpc_error_code": "RPC_ERROR",
  "app_error_code": "UNAUTHORIZED",
  "error": "An error occurred, applicationEC: UNAUTHORIZED, errorDetails: []",
  "content": ""
}

bric-stripe commented 1 year ago

@TatsuUkraine thanks, that's good to know and to have an additional data point with livemode values. I found the logs for that request and can confirm its the same "Merchant ID does not belong to platform" but I can see in some tools that that livemode association to the platform account was setup today. So I'm still working with others to try to make sense of things here.

For that latest connected account attempt, acct_167TydEinD1x7gok, I see it has a test mode connection to the platform account already as well. Could you check if that account works in test mode? I'm not expecting it to just want to collect some more data points.

TatsuUkraine commented 1 year ago

I see it has a test mode connection to the platform account already as well. Could you check if that account works in test mode?

hm, strange, it probably was some time ago, but I don't think we have this env anymore. I can just try to connect it in test mode from scratch and check if it helps

TatsuUkraine commented 1 year ago

the Connected column under the Connect section in Main Stripe account is blank for acct_167TydEinD1x7gok, so it seems that acct_167TydEinD1x7gok isn't connected to the platform account in test mode. But I can try to connect it if you want

bric-stripe commented 1 year ago

OK, no worries. Thanks for checking. I may have been looking at something old. We should have enough data with the live mode logs.

TatsuUkraine commented 1 year ago

no problem. I'm looking at dashboard though, you have much more info about states and all of this) so I won't argue with you if it's connected in test mode or not 😁

Let me know if you need any more info from me.

Just a random question - do you think this issue may take days or weeks to figure out what is going on?) just trying to understand how far it may potentially push back Tap to Pay integration for us

matthewryan commented 1 year ago

@bric-stripe Thanks. I managed to get this working by trying on another device. Realised the only difference between the two devices was the first which was returning the network error was running a (slightly) out of date version of iOS 16. I've updated and that device is working now too. Sorry for distraction on this issue thread.

bric-stripe commented 1 year ago

@TatsuUkraine

do you think this issue may take days or weeks to figure out what is going on?

hard to say as its still unclear what the problem is, but hoping to know more early this week and will update as soon as possible.

TatsuUkraine commented 1 year ago

Thank you!

bric-stripe commented 1 year ago

@TatsuUkraine the teams involved in validating that an account belongs to a specific platform have helped us and they have made sense of the problem and estimate it will take over a week to get it fixed up (sorry, there's still some unknowns and multiple teams involved so hard to get a great estimate for you). Can you confirm this is the only thing holding up your tap to pay usage? Assuming this is the only thing blocking you I'll try to communicate that urgency to the other teams.

TatsuUkraine commented 1 year ago

@bric-stripe hi, thank you a lot for an update! So we did all work on the backend and frontend. Going to have a testing phase soon (this week or early next week), that is why I was particularly curious if we did something wrong with the integration or not, to understand if we can assume that it's testable at least on Android (meaning nothing will change in our codebase).

So if we no need to fix anything on our end, I mean if it's still issue not in our integration) then yes, this issue only one thing that holds us from rolling out this feature to our users. At least in iOS app.

At that point we trying to get at least approximate understanding of the timeframe. So we could plan release schedule accordingly

bric-stripe commented 1 year ago

curious if we did something wrong with the integration or not

nope. My limited understanding of the issue is its a Stripe side problem that can affect platform accounts created some number of years ago (I don't have a specific date). So this isn't anything new or anything related to your integration with TTP.

to understand if we can assume that it's testable at least on Android (meaning nothing will change in our codebase)

yep, my understanding is this should be a fully backend fix on the Stripe side that won't require changes from you.

TatsuUkraine commented 1 year ago

Stripe side problem that can affect platform accounts created some number of years ago

Ah, I see, good to know

yep, my understanding is this should be a fully backend fix on the Stripe side that won't require changes from you.

Ok, in that case I would say yes, this issue only one item that holds us from TTP release for iOS users

TatsuUkraine commented 1 year ago

Thank you for the info!

bric-stripe commented 1 year ago

@TatsuUkraine the Stripe side fix for this issue has been deployed. Could you confirm that your accounts are now able to connect?

TatsuUkraine commented 1 year ago

@bric-stripe awesome, than you! I will try to confirm it tomorrow with test and live modes and let you know what results are

TatsuUkraine commented 1 year ago

@bric-stripe so I did a small check in test and live modes with accounts that had problems with linking - it seems all works as it should

TatsuUkraine commented 1 year ago

Thank you!)

stripe / stripe-terminal-ios