#josha_api

1 messages ¡ Page 1 of 1 (latest)

pallid oceanBOT
#

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

📝 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.

onyx prawn
#

Hello. Our use case is such:

  • We want to take payments from onboarded, returning user accounts
  • Our product sales flow takes the form of an on-session preauthorization > timely, real-world behavior which affects final price > payment finalization

We manage our own Card association UX. To date, we've implemented all of the above behavior with Cards like:

  1. User adds a card, which is associated to a User's account
  2. User selects a previously-saved card to use for a transaction
  3. User initiates a transaction process, on session, in the app, triggering us to issue a preauthorization
  4. Real-world behavior happens which affects final price
  5. Server observes this real-world behavior, finalizes the payment with the previously-associated Card from Step 1 and configured in Step 2

Now, we're trying to understand how the mechanics of Apple Pay fits (or not) into these steps

#

It seems like (and it'd be helpful to have confirmation) that Apple Pay Payment Method ids are unique to each transaction? If so, it would seem like we need to rework our flow to not associate an Apple Pay PM id (e.g. Step 1) and, instead, handle those PM ids as ephemeral ids?

worthy lava
#

Hi, what do you mean by 'finalized later' flow? What integration guide are you following? What do you expect to see vs what is happening when you test this?

onyx prawn
#

Practically, our app manages payments for diesel purchases. The user initiates a transaction from our app, fills up a certain amount of diesel fuel, our backend sees this and can compute the final cost, then we finalize that transaction with the final price. I'm pointing this out because, while we do use the PM later, it's not of a, e.g., subscription model. It's only used one time in the future, in a specific transaction context.

#

My question is if we should be associating Apple Pay PM ids to User accounts, like we're currently doing with Cards, given the context of our purchase process?

worthy lava
#

Ah, ApplePay payment method should work similar to Cards.

#

Are you seeing any errors on your end?

onyx prawn
#

There's no existing behavior to validate here. I'm trying to understand the model.

worthy lava
#

I see, yes it should work the same.

onyx prawn
#

Do Apple Pay PM ids change between transactions?

worthy lava
#

Hmm, if you've saved the payment method no. You just used the same payment method id like you would do with Card payment method types.

#

I highly recommend that you test this using your Test API key. Playing around with these is helpful to understand how it all works.

onyx prawn
#

What happens in this scenario:

  1. User transacts with Apple Pay, selects Card A to use from their iOS Wallet
  2. Our backend associates the generated Payment Method ID to the User
  3. User transacts again with Apple Pay, selects Card B to use from their iOS Wallet

Will the generated Payment Method ID after Step 3 be the same as in Step 2?

#

And will applying a charge to the original Payment Method ID a second time result in Card B being charged?

worthy lava
#

Yes, since that is a different card it would.

onyx prawn
#

Yeah, I'm aware of how cards work, in this way. Where I'm consfused is Apple Pay wraps the card selection but, itself, has its own PM id.

#

Is that PM id tied to the card the user selects in Apple Pay? I would have expected it to be ephemeral, considering transactions are always configured through Apple Pay.

worthy lava
#

Can you test this in your flow and ensure that it works? When you charge the second time, are you creating the payment intent on the server side and passing the existing payment method?

onyx prawn
#

ok, we'll do that. thank you!

worthy lava
#

If you do not pass the existing payment method, just like cards, it would create another payment method.

pallid oceanBOT