Useful Blogs for App Promotion
500,000 monthly readers are maximizing their advertising conversions with conversion intelligence.
The average online user is exposed to anywhere from 6,000 to 10,000 ads every day.
Dec 31 2020
Recently, the official news from the Apple App Store mentioned information about customer authentication, and that starting December 31, 2020. EU legislation introduced strict customer authentication (SCA) requirements for users in the European Economic Area (EEA), which could affect the way they complete online purchases. And for games and apps with in-app purchases, have their developers prepared for this in advance? The App Store and Apple Pay will then support strong customer authentication, and you'll need to verify your application’s implementation of StoreKit and Apple Pay to ensure purchases are processed correctly.
ASO World will go over the key points with you, and if your app or game includes in-app purchases, and your target market includes the EEA, you'll need to be further confirm that you're prepared accordingly.
Strong Customer Authentication is a set of rules for identity verification introduced by your bank or payment service provider to maximize the security of your funds and limit fraud. 2019 sees the introduction of a new rule in the EEA called Strong Customer Authentication (SCA), designed to further enhance payment security and limit fraud.
The settlement process for online purchases in the EEA is said to involve SCA and is expected to come into effect on December 31, 2020. For Apple App Store app developers, you need to go and pay attention to whether your in-app settlement is affected.
Strong Customer Authentication (SCA) is a new regulatory requirement out of Europe that requires payers to confirm autonomous acceptance of payments and the need to meet SCA requirements, and you need to have another identity verification built into the checkout process. Specifics include the need for dual authentication for many online bank card payments in Europe. Without such authentication, many payments may be declined by the customer's bank. This rule is intended to reduce fraud and improve the security of online payments.
Traditional card payments typically involve two steps: authorization and capture. The customer's bank or card issuer decides to approve a payment, which is considered an authorization, and performs a charge-back on the card, which is considered a capture.
With SCA, an additional mandatory step is required before authorization and capture: verification. This step helps protect the customer against fraud. To validate a payment, customers need to respond to their bank's request for information and provide additional information accordingly. This could be information they know, such as a password; it could be something they use, such as a phone; alternatively, it could be a part of their body, such as a fingerprint.
One of the most common ways to verify payments is through 3DS authentication. This can be identified by its brand name, such as "Visa Secure" or "MasterCard Identity Check". A new version of this method is now available, called 3DS 2.0 Authentication, which is expected to become the standard payment verification method.
Regardless of the method you use, the customer must participate in the session and give the verification in person, that is, they must use your website or application. This step is easier to add for companies that collect payments directly from customers; it's more complicated for companies that collect payments after the customer leaves the checkout process (Sometimes referred to as "out-of-session").
The Payment Services Directive (PSD2) is an EU regulation that requires strict customer identity verification (SCA) for certain online purchases to prevent fraud. In app stores, apps that initiate certain transactions via credit or debit cards must be authenticated by a bank or payment service provider before they can be completed.
For developers with in-app purchases whose target market includes the EEA, the following points need to be addressed:
So app developers involved in-app payments need to check if your users are having trouble with the payment process, and can consider payment channel options, etc. to improve the problem accordingly.
For in-app purchases that require SCA, the system will prompt the user to verify their credit or debit card. They will jump out of the purchase process, go to their bank or payment service provider's website or app for authentication, and then be redirected to the app store. They will see a message here informing them that the purchase has been completed. Handling this interrupted transaction is similar to a "purchase" endorsement that requires approval from a home approver, or an updated App Store terms and conditions that the user needs to agree to before completing the purchase.
Make sure your app can properly handle interrupted transactions by initializing the transaction observer to respond to new transactions and synchronize pending transactions with Apple. The observer helps your app handle SCA transactions, and when a user exits the app, the SCA transaction can update your payment queue with a "failed" or "delayed" status. When a user is redirected to the app store for authentication, a new transaction with a status of "Purchased" is immediately delivered to the app developer and may include a new value for that transaction Identifier property. You can test broken purchase scenarios in a sandbox for a specific sandbox Apple ID.
Apple Pay includes built-in authentication and does not require additional authentication from your bank. However, to avoid payment issues when using Apple Pay, on your app, make sure you use the correct country code in your payment request and that the final amount is shown on the payment form.
The value on the country code for PK Payment Request (for the app) and Apple Pay Payment Request (for the website) should be set to the correct two-letter country code in the country where you are processing the funds. Setting the value here correctly ensures that the PSD2 compliant code is used when both the merchant country code and the user's card issuer are located within the EEA.
Show the final amount on the payment form instead of the pending amount. This will facilitate a dynamic link where the transaction amount and merchant identifier are included in the password to prove the origin and authenticity of the transaction.
Of course, you can also use other third-party collection channels, but before doing so you need to confirm that these collection service providers have opened specific payment API based on the new SCA rules that can help you cope with this change and take advantage of all possible SCA exemption opportunities.
Given that implementation is approaching, we recommend that you prepare your payment processes so that you are ready for the SCA as soon as possible. As European banks increase their implementation of these requirements, this will help prevent an increase in drops and prevent the loss of customers during multiple parts of the certification process. The new Payment API and other solutions that support SCA is designed to take this uncertainty into account.
Get FREE Optimization Consultation
Let's Grow Your App & Get Massive Traffic!
All content, layout and frame code of all ASOWorld blog sections belong to the original content and technical team, all reproduction and references need to indicate the source and link in the obvious position, otherwise legal responsibility will be pursued.