#demodian_react-native-terminal

1 messages · Page 1 of 1 (latest)

vagrant starBOT
#

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

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

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.

dry ocean
#

PHP side:
$payload = [
'amount' => $amount,
'currency' => 'usd',
'payment_method_types' => ['card_present'],
'capture_method' => 'manual',
'application_fee_amount' => $servicefee,
];
$intent = PaymentIntent::create($payload, [ 'stripe_account' => $acct ]);
$result = [ 'client_secret' => $intent->client_secret ];

lament gorge
#

Hi there

dry ocean
#

hi

lament gorge
#

What does "it does not seem to work" mean?

#

Are you seeing an error?

dry ocean
#

yeah, an error message pops up

lament gorge
#

What error

#

Ah you are passing in the client secret here

#

For the React Native SDK you need to pass the entire PaymentIntent object

dry ocean
#

doesn't like the fact that i'm passing the secret in
const { paymentIntent: collectedPaymentIntent, error: collectError } = await collectPaymentMethod(clientSecret);

lament gorge
#

You should retrieve the full PaymentIntent using the clientSecret first and then pass that full object

dry ocean
#

ahh, will check the link real quick

#

gotcha. was trying to make sense out of the example RN app, which also creates the PI in the app itself

#

btw, it's still hit-or-miss getting the M2 reader to connect from the support issue on the 17th

#

it still takes a few attempts to get a connection

#

not perfect, but I can connect sometimes. still getting this:
connectReader error {"code": "READER_ERROR.BLUETOOTH_DISCONNECTED", "message": "Bluetooth unexpectedly disconnected during operation."}

#

if i try discovery again, it might catch it. been trying to refrain from factory resetting the M2

lament gorge
#

Hmm do you have an open support ticket for that issue?

#

Because it likely needs investigation from our Terminal Engineers at this point if you aren't able to connect reliably.

dry ocean
#

i can follow up on that in a bit

#

i added the following:

console.log('clientSecret', clientSecret);
const { paymentIntent, error: retrieveError } = await retrievePaymentIntent(clientSecret);
console.log('paymentIntent', paymentIntent);
if(retrieveError) {
setPendingMsg('Error');
Alert.alert("Error retrieving payment intent", retrieveError.message);
return;
}
// TODo handle error
// use the secret to collect the payment method
const { paymentIntent: collectedPaymentIntent, error: collectError } = await collectPaymentMethod({ paymentIntent: paymentIntent });

#

but now I'm getting Error retieving payment intent: No such payment_intent: 'pi_3RtXE5G9Rgv0LRak0wily6IT'

#

but the example in the link you sent was:

const { paymentIntent, error } = await retrievePaymentIntent(clientSecret);

#

not sure how to fix this retrieval...

#

i can paste the last client secret, if you need it

#

clientSecret pi_3RtXE5G9Rgv0LRak0wily6IT_secret_0acdsqhv9xKGT6gYUEQBgXvHV

lament gorge
#

Are you using Connect here?

#

If not, did you double check you are using the right keys?

#

Like matching publishable and secret?

dry ocean
#

yes, trying to use with connected accounts

#

should we use our main keys and not the connected accounts?

lament gorge
dry ocean
#

okay. let me switch that real quick

vagrant starBOT
dry ocean
#

our secret key or public key?

lament gorge
dry ocean
#

how best should I do this if I do not know WHICH connected account I will be using when I have the StripeProvider element? We have a process of the user logging in and selected the event they are using, so we don't have access for the connected account until then

split peak
#

👋 Taking over this thread, catchiing up now

#

In this case, you should render StripeTerminalProvider component when the connected account becomes available

dry ocean
#

when I tried having that anywhere other that the root, it didn't want to run

split peak
#

Is your connected account available at initialize()?

dry ocean
#

no

split peak
#

Since the user will only be able to access the terminal feature after logging into their account, why would you initialise before that?

dry ocean
#

it is structured like:

index.tsx:
<root>
<StripeProvider ...>
<App>

App.tsx:
<App>
(initialize happens here)
<AppScreens>

AppScreens.tsx:
<AppScreens>
<RootStack> from createStackNavigator()
<RootStack.Screen ... for login, event selection, home, etc>

#

because I'm a RN/Expo novice and I've been cobbling things together because the ecosystem is damn weird....

#

we have a web-based POS using Terminal SDK, but the only reader we had available originally was the Wise POS internet-based reader, but we can't force our connected accounts to buy those all the time, so we tried using the RN Terminal SDK to connect to the cheaper readers (like the M2) via bluetooth.

#

unfortunately, by the point we know what event we will be connected to, we are already in the screen stack, and I'm not sure how we would segment that apart, since we have to allow logout and event re-selection from within the stack

split peak
#

initialize() is the step to fetch the connection token. It should be only called when the connected account becomes available. Otherwise, it won't be able to connect to the reader on the connected account

#

Use useEffect() to call initialize() when connected account is not null / undefined for example

dry ocean
#

i really didn't want to tie it to specific screens, which is sounding like what I would have to do. when at the events, we would need the app to be ready to go to quickly process payments, so initializing only on those screens sounds like lots of duplicated code

#

or it would require fragmentation of the screen navigation, which was an utter mess, because we had it originally like that

#

can i do this?
initialize terminal SDK with my main secret
ANY reader connections will be done versus my main secret (though locations are still specific to the connected accounts, since locations are required to connect to the readers)
ANY card purchases will need the connected account ids for payment intents for the processing

#

(that would mirror more of what we are doing on the web version)

split peak
#

Are you collecting the payments on the connected account, or platform?

dry ocean
#

platform on behalf of the connected accounts because we have a application fee we collect

#

(but we don't know the connected account id until we are already in the screen stack in the app. in the web version, we are already aware of the connected info by the time the POS is started because the user is already logged in and event selected prior to starting the POS)

split peak
#

Sorry if my question is confusing. Which charge type (https://docs.stripe.com/connect/charges) are you using, Direct Charges, Destination Charges or Separate Charges & Transfer (SC&T) for connect integration? Direct Charges create the payment intent on the connected account whereas Destination Charges and SC&T is on platform, then transfer to connected account later. All of them support application fee.

Different charge type will result in different connection.

Create a charge

Create a charge and split payments between your platform and your sellers or service providers.

dry ocean
#

direct, on behalf of connected account, as we pull our application fee first, and then the rest goes to the connected account

#

(we did it that way so we are not responsible for charge backs and such, nor are we holding back their funds based on transfer delays)

#

<StripeProvider
publishableKey="pk_test_51RtDQPGdyoQ7SsQlw0TZKRkZQ7IIQdGrwat7Hjw8hYeU4wGz7ZokZvKM2uf2TyjWgoZtfPy6L1Sa14HfZ0jPkJln00FSpLRz86"

  stripeAccountId={{CONNECTED_ACCOUNT_ID}}

>

it would be awesome to have a way to set the stripeAccountId later, because the provider doesn't like being in a screen

#

(the provider doesn't like the initialize being in the same layer either, which is why I had to put it in the App layer under the root layer)

split peak
dry ocean
#

<StripeTerminalProvider logLevel="verbose" tokenProvider={fetchTokenProvider} >
<App />
</StripeTerminalProvider>
is what i have in root layer

#

this has been all for Terminal SDK

split peak
#

This looks correct to me. At this point, the terminal provider is not initalised yet

dry ocean
#

right, i have the initialize code in App.tsx

#

(because the useEffect()s could not be in the same file - index.tsx)

#

q: do i need to initialize the RN terminal sdk with our platform secret key?

split peak
#

I'm afraid there is no other workaround to call initialize() only after connected account becomes available. tokenProvider will only be called at initialize() to allow the access the readers on the connected account

#

Secret key should only be used at server side

#

You should never use secret key at any client side SDK

dry ocean
#

that's fine. just verifying

#

so public key

#

so i have to fragment the screen stack..... damn.... (again, it would be awesome to have a way to change the connected account id)

vagrant starBOT
dry ocean
#

i'd rather have the initialize() done once, so i'm not having to re-discover the card reader for each card purchase

orchid lodge
#

Hi 👋

I'm stepping in as my colleague needs to go soon.

dry ocean
#

i've got about half an hour myself

orchid lodge
#

Unfortunately I think my colleague is correct. If you are swapping between connected accounts with the same reader, you will need to re-initialize and re-discover the reader for each Connected Account.

dry ocean
#

while logged in and the event is known, we won't be switching all the time. The workflow is login, select event, home and everything else. If i have to fracture the screen stack again, then fine, but it was such a kludgy process originally (before I even tried connecting the terminal sdk)

#

because we have to deal with the possibility of idiots not logging in properly or selecting the wrong event, so the setup allows for logout and event re-selection

#

but we cannot afford to re-initialize and re-discover for every payment, as the event needs to get people in the doors quickly

#

so one initialization is ideal

orchid lodge
#

That sounds like you'd need to manage the idiot possibility outside of the Stripe Terminal portion of the app. That way you could cut down on the number of re-inits

dry ocean
#

the problem has been that we do not know what the connected account is until the event is selected. i wish, i could deal with the idiot problem, but there's too many of them.... -_-

#

they're like weeds. guess i have to re-fragment the screen organization and bury the terminal sdk deeper than root

orchid lodge
#

That is unfortunate. Because you are doing direct charges, everything including the Connection Token needs to set on the Connecte Account. There isn't a way around that.

dry ocean
#

hopefully it will take less time to do it this go-around. I really hate RN/expo... the ecosystem is horrible

orchid lodge
#

Preach!

dry ocean
#

(the past 3 weeks were spent trying to create a bluetooth thermal printer driver that works with modern code, because all the recent modules are at least 4+ years old and don't function now, and I had to figure out how to make it work with RN-ble-plx, which was a bear. at least the terminal sdk is still being actively worked on)

#

(it's not fun constantly having to pull miracles out of my rear just to work with this bad ecosystem)

#

lol

orchid lodge
#

For sure. Even for packages that are actively maintained, I feel like RN is always operating at lowest common denominator between Android and iOS capabilties. Add in the delay in getting the SDKs updated for Expo and it gets even worse.

dry ocean
#

yup. if it wasn't for the bluetooth device requirement, I wouldn't have even started this app design and just kept our web version

#

but this has been my life for the past 4 months

orchid lodge
#

Yeah, mobile development just adds so many more layers.

dry ocean
#

and Tylenol dependencies....

#

i'll let you go, so i can get my laptop shut down, since i have to head home soon. will hammer on this tonight and probably bug you guys tomorrow after i've reworked the code a bit. will also follow up on the prior issue for M2 connecting, because it sometimes takes 2 or more attempts to successfully connect (even with 26-beta and the reader firmware update)

#

have a good rest of your day

orchid lodge
#

Gotcha, okay. We will be here, although some problems may require more debugging than we can do real-time in chat. But someone will be here to at least get that started.

vagrant starBOT