If you as a merchant would like to offer Apple Pay or Google Pay without your own merchant account, Computop Paygate offers the option of displaying both payment buttons directly on the credit card payment form using an additional configuration. As a merchant, you only need to order the payment method from your sales contact and we will carry out the configuration for you.
In the case of Apple Pay, it is also possible to activate the Girocard for your end customers; to do this, we also require a bank account to which the Girocard sales are then booked for you. The bank will be queried accordingly as part of the additional agreement.
Notes / Restrictions:
The Apple Pay solution on the form is not possible in the iFrame, if the credit card input form is currently loaded in the iframe, the Apple Pay button cannot be displayed. This is a limitation on the part of Apple.
The Apple Pay payment button can only be displayed using the Safari browser.
Please note that the Computop domain (www.computop-paygate.com) is displayed to the customer in the Apple Pay Wallet and it depends on the Computop Apple Pay account used and cannot be customized/changed.
Please verify that your current credit card acquirer also supports the two payment methods by default, we can gladly research and confirm this for you.
If you use your own template as a merchant, we can deliver the codes per payment type for this additional solution and you can store them in your own template. After that we need a template update from you and the solution can be tested.
You can recognize the two wallet payment types by the additional Type parameter that is returned in the response and the Notify. Example: "Type=ApplePay". This allows you to statistically evaluate how often Apple Pay and Google Pay are used.
The handling of follow-up transactions and credits remains unchanged as with classic credit card payments.
In addition, it should also be noted that the redirect for standard 3DS-2.X transactions is processed via POST to the URLSuccess/Failure. If an Apple or Google Pay payment is processed, the redirect is executed automatically via GET. There is a slight difference to the existing Notify mode (POST), meaning that the redirect is the first action and the Notify is automated about 1 minute after the redirect.
Finally, please note a change to the URLNotify process, in standard case of a credit card payment LEN+DATA posted in the Notify Body, in the case of an ApplePay form based transaction LEN+DATA+MerchantID posted in the Notify Body.
Using the Apple Pay button in WebViews:
Apple Pay on the web works for both webview technologies, regardless of whether it is implemented using Apple Pay JS or the Payment Request API. However, there are some scenarios where it is blocked in WKWebView for security reasons.
SFSafariViewController is a very secure implementation of a webview - the app developer has no way to read or interact with the content of the webview once it is presented - Apple Pay should always work seamlessly over this technology.
WKWebView is a much more powerful tool from a developer's perspective - it provides APIs to interact with and manipulate the webview content. If certain APIs are used, Apple Pay will no longer be available in Webview, as the use of these APIs could pose a security/data protection risk if used maliciously (e.g. the app could retrieve the personal data returned by the Apple Pay wallet without the user's consent).
example screen - Computop standard form incl. pay buttons:
