Helpers for / integration of Apple Pay

[nkuehn]

We could consider providing some helper functions for the Apple Pay Feature of iOS.
It's not live in Germany yet, but in USA and UK and Spain and the list of backing payment providers (PSPs) to be used is very interesting:

• https://developer.apple.com/apple-pay/ (at the bottom, e.g. Adyen, Braintree, Stripe, Worldpay, Authorize.net ... )
• https://developer.apple.com/apple-pay/get-started/

Use Case:

• payments for physical goods purchased in the end user shopping app (like sunrise demo).

Why Useful?

• (for app dev) will be the same or similar work and code for most apps (mapping cart to Apple Pay API, creating correct CTP payment resources to document the process)
• (for dev) quicker cut-through app development, earlier "success" feeling - it's hard to get stuck int the checkout
• (for commercetools) could make PSP integrations a little simpler, but only in certain cases.

Caveat: A PSP specific trusted Server component is still necessary to transfer the encrypted info to the PSP, have the PSP decrypt and do it and then pass back the "success" info to the app / CTP (we could try to add that to the existing Stripe integration)

---

edit: reduced bias and added caveat that it's "just" the checkout in-app part that's standardized then -> still requires a PSP integration.

[nkuehn]

ping @cneijenhuis what do you think?

[cneijenhuis]

I think there are two levels of doing it:

• Frontend: Present the Payment Sheet, get the token from Apple Pay and throw it away.
• Full: Use the token with a PSP. This would make most sense if we have an adapter for this PSP.

Frontend is not completely useless (for devs), as there is some mapping from Cart to Apple Pay going on - this will however also include some merchant decisions (e.g. present line items or only total amount? present shipping address?).

Frontend is probably nice for Demo purposes. I would propose to do it as part of sunrise demo first. I would move it to the SDK later if a) it is flexible enough to support multiple merchant scenarios and b) we achieved the Full level.

The roadmap for the first 2 months of Sunrise development is not yet finalized, but currently we're planning to do click&collect first (= no payment in app).

[nkuehn]

thanks, good Analysis. I updated the original text to be more precise.
My intent for this issue was only the Frontend Part - it assumes that a working PSP integration is handling the new CTP payment resource to have the PSP decrypt the data and do the transaction, all of which can't be done in-app anyways.

[cneijenhuis]

On another thought, it would be good if we do this along with /me/payments.

[nkuehn]

good point. I did wonder whether a me/payments is a good idea at all, there can be very "interesting" data in it, esp. in the raw interactions with the PSP. But you're right, without the possibility to create transactions from a password flow API client it's kind of pointless to do payment integrations.

[cneijenhuis]

We haven't designed this yet, and I will consult with you when we start this :wink: But my gut feeling is that interactions should not be returned from /me/payments.

[nikola-mladenovic]

Since we did the Apple Pay integration in the new version of Sunrise iOS app, I wanted to revisit this issue and discuss whether we still like to offer some methods to make it easier for others to potentially integrate it using our SDK.

Here's the code related to Apple Pay SDK <-> CT SDK: https://github.com/commercetools/commercetools-sunrise-ios/blob/master/Sunrise/ViewModels/Cart/CartViewModel.swift#L364:L536

The way I see it, it'd be nice to have some extensions and helper methods to update the active cart based based on customer's actions with the apple pay UI + transforming models from AP SDK to CT SDK and vice versa (e.g PKContact <-> Address from CT SDK, PKShippingMethod <-> ShippingMethod from CT SDK, etc).

First, I'd like to hear from @nkuehn @cneijenhuis if you agree, and if so, it'd be great if @cneijenhuis could have a glance at the existing iOS app implementation, and provide some feedback.

After that, I'd write specs proposal and take it from there.

[cneijenhuis]

I still think the idea is a good one, would be great to see this moving along!

I'm afraid I won't have the time to dive into the details of it, though :(