#taylorbrooks-terminal

1 messages · Page 1 of 1 (latest)

errant horizon
empty flower
#

Ah shoot, I was trying to move my reply to the thread.

errant horizon
#

hey there! can you explain more about the use case here?

#

It's ok, i saw it

#

trying to add a payment method to a payment intent without capturing it

empty flower
#

yep, that's it

errant horizon
#

correct? 👆

#

YOu can use manual capture with Terminal payments, if that's what you mena

#

capture_method=manual

empty flower
#

Right, we currently do that.

errant horizon
#

the difference from online payments if that you only have 2 days to capture, instead of 7

#

ok

#

What are you havent trouble with exactly? what would it mean to call process payment multiple times, for you?

empty flower
#

Yes, is calling Terminal.shared.processPayment() multiple times allowable if you are not going to capture the payment intent in that initial function?

#

I can describe at a high level what we are trying to do if that would help

errant horizon
#

It would help to explain that i think, yes

empty flower
#

Ok great.

#

Currently, we run collectPaymentMethod and then we ask for information about the person (first name, last name, email).

Our thought was, if the person has used this same payment method before, we should know that and just not ask for person details. We should just immediately capture.

So our thinking was:

  1. Collect payment details from the reader.
  2. Look up the payment details associated with the payment intent.
  3. See if that card fingerprint has been used before. If so, return the person data. If not, prompt for collecting person data.
  4. Capture the payment intent.

I think we are stuck on step 3 because:

  1. Payment details aren't associated with the payment intent on collectPaymentMethod
  2. It appears payment details are only "attached" to the payment intent when processPayment is called.
  3. It appears processPayment can only be called once, because we are getting errors on the second call.

Sorry that's a lot to ingest, I hope it makes sense. I can clarify if there is anything unclear.

errant horizon
#

Rightm, so if successful you'd only be able to call that once. After the payment intent is confirmed successfully with the collected PM you can't do that again.

#

I think for you use case deferred capture makes sense you could:
1/ create the payment intent with manual capture
2/ collect payment method
3/ process payment
4/ check those details you need
5a/ if complete, great, capture via server
5b/ if incomplete, use POS to collect details
6/ after missing details collected, capture payment via server

#

The key is that the capture is happening on your server, so your pos and server will need to work together to achieve the overall result

empty flower
#

I like what you wrote, but I'm not sure how its different from what we are trying to do.

Steps 4 to 5 are where we are having issues.

errant horizon
#

the checking, or the capturing?

empty flower
#

Our "checking" method is getting the fingerprint (from the payment intent) and calling an API in our system that looks up a customer based on the the fingerprint.

I don't know how to get the fingerprint w/o calling processPayment()

errant horizon
#

I'm saying you do call that first, though

#

process then check

empty flower
#

My understanding is you have to process/capture synchronously. Maybe that's not the case.

#

Yeah from the docs: "Your app must synchronously notify your backend to capture the PaymentIntent in order to settle the funds to your account."

errant horizon
#

Where are you reading that?

empty flower
errant horizon
#

And yes, when manually capturing you do need to do that, but after processPayment with manual capture, you should be able to inspect the authorized payment intent with the payment method details you need

#

then you can collect whatever you need before you call /capture for that payment intent

empty flower
#

K, we can try it. My hunch was that I would get a different error based on what the docs said.

errant horizon
#

Ah hold on - i might have confused myself here

#

Right, the manual capture is part of this for terminal, apologies I'd forgotten that

#

OK

#

so, can you not check for those details you need in between processPayment and capture in the existing flow?

empty flower
#

Sure, but I'm not sure how that would work if I need to capture new person info.

errant horizon
#

Well maybe we need to consider what you're doing with this info when you need to collect it. You only mentioned name & email earlier, which sound like details you'd store on a customer object.

#

In which case you'd add a step to collect this in your POS, update the customer, then process to /capture the payment intent

empty flower
#

Which we are currently doing, but we don't want to ask for information we already have if the same card was used before.

errant horizon
#

Hmm i think there's a piece missing between us

#

lets say you have all the info

#

you call process payment, look at the payment intent, payment method, seems good, proceed with capture

#

great

#

in the case of missing info

#

you collect payment method, process payment, look at the payment intent/payment method for what you need and find its missing

#

so before going ahead with the capture, your POS then tries to collect those details and save them on a customer

#

then you go ahead and capture

#

I think i'm not understand some part of what you need to do, so can you explain precisely where this falls apart for you and doesnt suit your needs?

empty flower
#

"so before going ahead with the capture, your POS then tries to collect those details and save them on a customer"

I think this is what we need to figure out on our side.

The linchpin question is:

  • Can we present a modal in the UI that prompts for person data, while we are in the inside the processPayment function?

If we can do that we are golden.

errant horizon
#

Have you tried doing so? This would be something your POS needs to manage, its not provided by th Terminal SDk