Google Pay and Apple Pay

[Lachlan Gemmell 33]

I'm doing some early investigation into the feasibility of an FMX application that can use Google Pay and Apple Pay on their respective platforms. The first stumbling block I've found reading their documentation is that they both require you to use a particular specialised native button provided by their respective payment SDKs.

 

PKPaymentButton for Apple Pay

https://developer.apple.com/documentation/passkit/pkpaymentbutton

 

PayButton API for Google Pay

https://developers.google.com/pay/api/android/guides/resources/pay-button-api

 

FMX has some rudimentary support for native controls so presumably it would be technically possible to make use of these buttons, the question is how much work would be involved. I'm guessing quite a lot but maybe someone here knows more?

[Dave Nottage 562]

9 hours ago, Lachlan Gemmell said:

I'm guessing quite a lot but maybe someone here knows more?

I've done something similar for the AppleID button, here and here, and I suspect PKPaymentButton will be similar. You'll need an import for PassKit, too.

 

As for the PayButton from Google, you'll need to get the play-services-wallet package (which means obtaining any dependencies not already in the "default" jars in Delphi), then import the relevant classes before creating the same kind of code as for PKPaymentButton, but for the PayButton, for Android, as well as writing the code that uses the PaymentsClient class.

[Lachlan Gemmell 33]

44 minutes ago, Dave Nottage said:

As for the PayButton from Google, you'll need to get the play-services-wallet package (which means obtaining any dependencies not already in the "default" jars in Delphi), then import the relevant classes

I'm assuming this the process you're referring to.

https://docwiki.embarcadero.com/RADStudio/Athens/en/Using_a_Custom_Set_of_Java_Libraries_In_Your_RAD_Studio_Android_Apps

 

45 minutes ago, Dave Nottage said:

before creating the same kind of code as for PKPaymentButton, but for the PayButton, for Android

OK, so an equivalent to your Apple ID button component in Kastri.

 

47 minutes ago, Dave Nottage said:

as well as writing the code that uses the PaymentsClient class.

Does this mean writing a Delphi wrapper around the Java PaymentsClient class? Can you think of any comparable code in Kastri for this task?

[Dave Nottage 562]

2 minutes ago, Lachlan Gemmell said:

I'm assuming this the process you're referring to.

Yes

2 minutes ago, Lachlan Gemmell said:

OK, so an equivalent to your Apple ID button component in Kastri.

Judging by the documentation for Wallet and PayButton, I expect it will be a bit more involved, but yes.

3 minutes ago, Lachlan Gemmell said:

Does this mean writing a Delphi wrapper around the Java PaymentsClient class?

If by "wrapper" you mean "Delphi code that uses PaymentsClient", then yes 🙂

10 minutes ago, Lachlan Gemmell said:

Can you think of any comparable code in Kastri for this task?

Perhaps the GoogleSignIn feature might come closest, however they're all fairly diverse (check units that end with .Android.pas in the subfolders of the Features folder). I expect using PaymentsClient (and the Wallet class) may be more complex than the others.

[Rollo62 538]

I wonder why Embarcadero is not offering an easy and stably native payment solution, or at least a valid tutorial howto get there.

This unclear technical base and very high risks prevents me from even looking much deeper into this topic.

Thats a pity, because the Payment is an essential feature in mobile, same as location, sensor access and web access, IMHO.

 

Perhaps the TMS FNC solutions are a more stable alternative, but I have not looked into this either.
https://blogs.embarcadero.com/create-native-and-secure-ios-wallet-enabled-apps-with-delphi-and-c-builder/

I'm afraid the preferred way will be to use external providers, such as Stripe or PayPal, to make things easier.

https://blogs.embarcadero.com/rapidly-deploy-blazing-fast-payment-solutions-on-windows/

 

I hope one day there will be a rock-solid, tested and approved solution for GooglePay and ApplePay anywhere, not just "proof-of-concepts".
 

[Lajos Juhász 295]

1 hour ago, Rollo62 said:

I wonder why Embarcadero is not offering an easy and stably native payment solution, or at least a valid tutorial howto get there.

 

Mobile platforms are changing very fast. Sometimes it is difficult for Embarcadero to provde a solution in a reasonable time frame when the new requirements are released to be able to continue to compile for new versions. Unfortunately nowdays Delphi support too many platforms. They are playing catch up games against other products. Delphi is by rule almost always way behind.

[Dave Nottage 562]

1 hour ago, Rollo62 said:

Perhaps the TMS FNC solutions are a more stable alternative

Not sure what you mean by "more" stable, if an out of the box solution does not exist? In any event, TMS PassKit is for VCL, and deals with PassKit files, not PassKit itself. 

[Rollo62 538]

54 minutes ago, Lajos Juhász said:

Mobile platforms are changing very fast. Sometimes it is difficult for Embarcadero to provde a solution in a reasonable time frame ..

Yes, that is true, but a reasonable timeframe and roadmap should be there.
I would like to see full support for such mission critical topics, either from Embarcadero or other from companies.

 

Now the whole risk is laying on the single developers shoulders, to find a reasonable solution, which will maybe result in many different problematic solutions out there.
Our clients have some expectations and we cannot provide solutions to all mobile features right now.

I was sure that TMS also had an integrated a solution in their TMS FNC too, but perhaps I was wrong with that,
at least they have support for all major external Cloud Payment providers.
 

 

[Lachlan Gemmell 33]

I've done a lot of website scouring over the past few days and the only third party vendor in the Delphi sphere offering out of the box support for Google Pay and Apple Pay is FGX Native.

 

FGX Native is not an FMX component library though, it's a complete alternative UI paradigm to FMX, and while I find it tempting I don't want to use it due to... reasons.