Until recently, we have all been using the 3D Secure protocol, which adds an extra security layer to prevent unauthorized online transactions.

Here’s more on that. 

What is 3D Secure? How does it work? 

3D Secure is a security protocol that includes processes, tools, and frameworks developed to enhance the safety and security of online credit and debit card transactions. 3D refers to the three domains that interact while using the protocol: the merchant or acquirer, the buyer or issuer, and the interoperability domains. These domains work together to verify the cardholder’s identity and ensure the transaction is legitimate. 

When a cardholder purchases online, the 3D Secure protocol authenticates their identity using a password or a one-time code sent to their registered mobile number. This additional step helps ensure only the card’s rightful owner is making the transaction. 

The merchant then sends the transaction data to the issuer domain, which verifies the card details and checks if the transaction is within the cardholder’s credit limit. If everything checks out, the issuer sends an authorization code back to the merchant, and the transaction is completed.  

3D Secure has become an industry standard for online payment security and fraud protection. It is widely used by major card networks, including Visa, Mastercard, and American Express. 3D Secure also allows businesses to hold the issuer bank liable for chargeback and fraud, reducing revenue leakage and increasing profitability.  

Where does 3DS 1.0 fall short?  

3DS 1.0 has been a popular fraud mitigation tool. However, this security protocol has a few limitations that stem from – 

• Poor user experience: Some users are unable to view the 3DS authentication page on their devices. Manually typing OTPs, PINs, and passwords can be a hassle.  
• Lower success rates: This is typically caused by the added step required for authentication. 
• Multiple password management: Remembering different passwords for each account is inconvenient.  

The friction in user experience causes high chances of cart abandonment and transaction failures. This is bad news for any business. But there is a solution to that. 

Introducing 3DS 2.0  

3D Secure 2.0 is an update of the original 3D Secure protocol, providing a more streamlined and user-friendly experience. The new protocol is developed by EMVCo, a global organization that facilitates the interoperability and acceptance of secure payment transactions.  

Key features of 3DS 2.0 

• Includes modern authentication methods such as biometric recognition, one-time passcodes, and mobile authentication. This enables a convenient yet secure checkout process.  

• Has the ability to collect additional transaction data such as device location, user’s location, and merchant’s transaction history. This helps issuer banks make more informed decisions around accepting or declining a transaction, reducing risk while improving user experience. 
• Improved risk-based authentication, allowing issuer banks to set risk thresholds for different types of transactions. 

3DS 2.0 is the logical next step in the evolution of digital payments as their popularity and e-commerce grow faster. Businesses need to adopt the latest security protocols to protect customer data and provide a seamless, secure checkout experience. According to Visa, 3DS 2.0 reduces – 

• Checkout times by 85% 
• Cart abandonment by 70% 

3D Secure 2.0 authentication mechanisms  

1. Frictionless Flow 

An authentication method that enables a seamless and effortless checkout experience. It uses behind-the-scene data analysis to assess the risk of a transaction. If the risk is low, the authentication process is completed automatically without intervention from the customer. This means the customer does not need to enter another password or code to complete the transaction. Frictionless flow is ideal for low-risk transactions and provides a smooth checkout experience. 

2. Challenge flow 

This method requires customer interaction to complete the transaction. Challenge flow is triggered to prevent fraud in high-risk transactions or when additional authentication is required. In this case, the customer is prompted to enter additional information to verify their identity, such as a one-time password sent to their mobile device. 

Adopt PayU’s robust 3DS 2.0 SDK  

PayU has launched its 3DS 2.0 software development kit (SDK) – the industry’s first 3DS 2.0 SDK – certified by EMVCo. The solution is lightweight (<100KB) and easy for businesses to integrate. Developers can find all comprehensive integration guides here.

PayU’s 3DS 2.0 SDK can enable merchants to always provide a secure and seamless checkout experience. Click here to read the complete 3DS 2.0 SDK integration guide.

The post What is 3DS 2.0? How it Works, Features and Benefits appeared first on PayU Blog.

Tina has been saving up for a few months to buy a new smartphone. She finally comes to your online electronics store looking for a good deal. After browsing for a while, she decides to go with her top pick. Although out of her budget, she hopes to get an easy financing offer. She excitedly adds it to the cart and proceeds to checkout. This is when she finds the offer is unavailable with her preferred payment mode. Disappointed, she leaves the site, possibly never to return again.

This is just one scenario in which you can lose a potential customer. Tina could have made a more informed decision if the payment options were visible when choosing the product. It also means your business would have fewer cart abandonment issues and higher revenue. This is exactly what PayU’s Affordability Widget can help you with.

What is the Affordability Widget?

PayU recently launched the Affordability Widget as the latest addition to its Affordability suite. The widget sits right on the product page and makes it easier for customers to see all available offers, EMI plans, and BNPL options in one place. They don’t have to go to the checkout page to know if they can actually buy the item.

How the Affordability Widget helps increase revenue

It is amazing how a simple solution can solve massive business use cases like cart abandonment due to low offer discoverability and transparency. Affordability Widget provides many benefits to both businesses and their customers.

Benefits of the Affordability Widget for businesses

Customers today are very savvy and appreciate an array of choices – whether it is products or payment modes. And clearly displaying them is as important as having them. By using the Affordability Widget, you can:

• Improve the discoverability of different offers and payment modes associated with each product
• Influence purchasing decisions right from the product discovery stage
• Impart branding at every stage of the purchasing journey
• Reduce cart abandonment and improve sales, resulting in higher revenue

All of these factors play an essential role in increasing revenue through transparency and trust.

Benefits of the Affordability Widget for customers

Customers deeply value experience, often as much as product and service quality. With the help of the Affordability Widget, your customers can:

• Make informed decisions early in the purchasing process
• Easily buy the products of their choice through affordability options and flexible payment modes
• Enjoy a smoother shopping and checkout experience

With the option to quickly calculate EMI and interest rates, customers can choose the best financing options based on their purchasing power.

Try the Affordability Widget for a bigger business impact

Now consider this. Giving consumers like Tina the option to pay through their preferred modes is a basic expectation today. Additionally, providing offers that make it easier for them to buy your products can significantly improve your sales.

The PayU Affordability Widget is an excellent solution to help you grow your business with minimal investment. Increase your sales by showcasing options like cardless EMI, no-cost debit and credit card EMI, and Buy Now Pay Later that improve affordability. You can easily integrate the widget on your online storefront using a simple JavaScript-based code and customize it to reflect your brand. There is also a detailed guide on the Affordability Widget and its integration.

Want to see for yourself? Click here for a quick demo.

The post A Genius Solution for Simpler, Smoother Shopping Experiences and Higher Revenue appeared first on PayU Blog.

PayU provides payment gateway solutions to online businesses and serves more than 5,00,000+ merchants with over 150+ payment methods. It is the preferred payment partner for e-commerce merchants, including all leading e-commerce companies and a majority of airline businesses.

PayU has a host of mobile SDKs that play a vital role in powering payments in our merchant apps. Our primary focus is to make integration on the PayU platform as simpler and seamless as possible with minimal efforts required by businesses.

Let’s talk about how we built our PayU Crash Reporter SDK and integrated it into all of our SDK offerings to adopt an early repair strategy.

Problem Statement  

PayU distributes SDKs via public repositories such as Maven Central Cocoa Pods, where businesses integrate them into their Apps. When a crash used to occur in our codebase, it was getting logged on the merchant’s crash tools dashboard, and the same was conveyed to us later. We were not able to monitor the crashes in real-time. Debug time was high since required debug information was not always available easily from merchant dashboards. At times it was difficult for us to de-obfuscate the stack traces due to the lack of SDK version information and the corresponding mapping files.

Exploration

We tried to solve this problem with multiple products available in the market like Crashlytics, ACRA, BugSnag, but none of them worked out of the box for us. Here’s why we could not solve this problem:

• The coexistence of multiple such solutions within a single app was technically impossible, as all of these solutions need a single unique id to be configured at the application level.  
• These products did not support Library Modules. Usage is restricted for Application-level projects only.  

We came across Sentry, an open-source solution that could solve the problems mentioned above.  Sentry has an SDK product that was able to solve our primary goal of monitoring crashes in our SDK, but it had some of its challenges as well:  

Large Size: The size of Sentry SDK is ~1000KB as it offers a lot of other features which were not of our interest, viz.Health monitoring, NDK crash reporting, etc.  

Control over Data: We wanted tighter control over the data as the Sentry SDK was capturing a lot of data points, which was again of no interest to us. Also, the payload size was bloated because of the same.  

The Final Approach

We have developed our own PayU Crash Reporter SDK (using Sentry) to resolve the above problems. The PayU Crash Reporter SDK registers itself with a Global exception handler to parse the stack traces and report only those crashes which occur in PayU SDKs. High-frequency events would then get picked up into our sprint cycles or as hotfixes for proactive issue resolution, thus creating much more stable SDKs.

Size: It’s around 40 KB, almost 1/25th size of Sentry SDK. We were able to reduce the size by this much by removing all the bloatware.  

Control over Data: Reporting only necessary fields such as library version, transaction id, details of all of our modules present in the merchant application, along with Stack traces to ease out the debugging.  

Stability: PayU Crash Reporter is completely written in Kotlin using modern practices such as Coroutines to make network calls lighter, improving stability.  

Extensibility: PayU Crash reporter SDK has been designed in such a way that it is being used by all of our SDK offerings for Crash monitoring.  

Getting Better

With PayU Crash Reporter SDK integrated into all of our SDKs, we were able to provide a smooth and stable experience to all of the 150+ merchant bases.  

One of the recent examples is a top e-commerce player in our country, having millions of DAUs, facing a crash in our SDK during low memory in the devices, causing poor customer experience. We discovered and fixed this issue in the early release stages of the App itself with the aid of our PayU Crash reporter SDK.  

Apart from this, frequently occurring crashes like – Unhandled exceptions / NumberFormat Exceptions, IllegalArgument exceptions, NullPointer exceptions, etc., were observed during runtime by the PayU Crash Reporter SDK and were immediately fixed in the subsequent releases of respective SDKs.  

Everything You Need to Get Started

You can look at a variety of payments SDKs that PayU offers for a seamless payments experience – Android iOS.   

For any integration related support, please reach out to your key account manager or write to us at mobile.integration@payu.in  

The post How PayU Does Proactive Error Monitoring for Mobile SDKs? appeared first on PayU Blog.

What were we doing?

We were moving from left to right (wrong) direction

As we tried to understand the problem — we realized that both the View & Controller depend on the Model. Also, the activities/fragments were holding both the UI logic as well as the controller logic. Because of this, our unit-testable code was diminishing & the code was becoming unmanageable.

MVC Structure

MVVM as a savior

We started our lookout for better architecture and this is when MVVM came in as a savior. Even, Google ❤ MVVM.

MVVM stands for Model-View-ViewModel:

1. 1. Model: It represents the data layer of the Application

1. 1. View: It represents the UI logic of the Application

1. ViewModel: It is a Model for a View. It acts as a bridge between the View and Model & does not have a direct reference to the View

MVVM architecture removes the tight coupling between each component. The children don’t have a direct reference to the parent, they only have the reference by observables. Notice that each component depends only on the component one level below it. This design creates a consistent and pleasant user experience.

Another important component in the diagram above is the Repository module. It handles data operations. It provides a clean API so that the rest of the app can retrieve this data easily. It knows where to get the data from and what API calls to make when data is updated. You can consider repositories to be mediators between different data sources, such as persistent models, web services, and caches.

LiveData is an observable data holder. Other components in your app can monitor changes to objects using this holder without creating explicit and rigid dependency paths between them. The LiveData component also respects the lifecycle state of your app’s components — such as activities, fragments, and services — and includes cleanup logic to prevent object leaking and excessive memory consumption.

Advantages

1. Separation of concerns: It’s a common mistake to write all your code in an Activity or a Fragment. The UI-based classes should only contain logic that handles UI and operating system interactions. By keeping these classes as lean as possible, you can avoid many lifecycle-related problems. MVVM lets you ensure that each type of class is responsible for only one type of task.
2. Testability: User interface and interactions can be tested using instrumentation test cases (Espresso Library). ViewModels & Repository can be tested using the JUnit test.
3. Scalability: You can easily introduce UI revamps. New features can be added without the need to refactor or change much of the existing codebase. We can plug and unplug the components with much more ease.
4. Manageability: The codebase is much more manageable – All your UI logic is in one place, your business logic & your data logic at another place.

Disadvantages

1. 1. Getting started with MVVM & adding new features may require some experience with the pattern. There is a steep learning curve, relatively.

1. Following the MVVM pattern, you might end up creating more Java classes.

Final words

While building any application it’s important to pick the right architectural pattern — there are no fixed “fits all” patterns.

In our case MVVM proved to be a useful pattern as we had a UI rich product that was subject to frequent UI revamps, we wanted to focus on the testability aspect of the product and we also wanted that there is a separation of concerns so we could do UI revamps by just changing relevant components of the codebase without touching rest of the codebase. MVVM architecture was just the perfect fit for us!

The post How PayU improved Testability using MVVM appeared first on PayU Blog.