Skip navigation
All Places > In the News > Blog > 2019 > March
2019

Our top question of the month comes from ptaysavang regarding the SecureNet API being retired. 

 

Check out his question and our answer here

 

 

If you ask or answer a question that helps our community members, you're automatically entered into a contest for a $25 Amazon gift card! 

Payments Developer Insights title card

 

 

We all know why developers are important. They write the software that makes the world run.

 

But how much do we know about who developers actually are? The answer, in many cases, is very little. After all, most developers work behind the scenes, hidden away from end-users. Unlike actors in a movie or authors of a book, developers rarely receive credit for their work. You might stand in line at the grocery store behind the person who wrote code for your email app, or who helped program your smart thermostat, but you’d never know it.

 

That’s part of the reason why Worldpay produced a survey of professional coders to figure out what makes developers tick. The survey doesn’t help raise developers from the anonymity in which they work, but it does provide critical insights into what payments developers are like, why they chose to become programmers, and what interests them.

 

Here’s a summary of key findings from the survey report

 

The path to a coding career

One major focus of the survey was understanding what leads people to become developers, and how they gain the skills necessary to program.

 

Perhaps unsurprisingly, the majority of professional developers said they have been coding at least since they were teenagers. Most also reported that they have been working as coders for at least 10 years.

 

Coloring that finding is the fact that, age-wise, it turns out that most developers are young. Millennials account for the largest share of the coder population today. Millennials also make up the largest portion of today’s workforce overall, so that is probably at least part of the reason why they are well-represented among the coding population.

 

How did all of these developers learn to code? The survey found that about half of developers learned to program via formal schooling. However, self-taught programmers accounted for a large portion (38 percent) of respondents. And somewhat surprisingly, a mere 4 percent of respondents said they learned to code through a programming bootcamp, suggesting that the interest that bootcamps have generated in the media in recent years is not proportionate to the number of people who actually become professional programmers through them.

 

Development tools and strategies

All developers write code, but the way they do it varies widely — and “modern” coding strategies are not as prevalent as you might think.

 

According to the survey, Agile stands out as the most popular approach to coding, with more than 57 percent of developers saying they rely on Agile methods. In contrast, DevOps, which receives lots of press these days, was among the least popular development methodologies, with only 4 percent of respondents saying they use it. Conversational development was the second-most popular approach, with 13 percent of developers embracing it.

 

When it comes to programming languages, Python is the most popular by far, with 39 percent of respondents identifying it as their favorite language. C++ was second, at 26 percent. Ruby and Java were both identified as favorites by only 9 percent of programmers, which I found surprisingly low, given how widely used these languages are.

 

Where developers work

Coders might be in their line of work partly because they like it, but most do it for a paycheck, too. When it comes to earning that paycheck, a majority of developers work solely in an office, although 38 percent said that their teams are allowed to work remotely, too. And while most developers work on small teams of two to five people, about a quarter work alone. (The survey didn’t distinguish between freelance developers and those employed by a company, so it’s hard to say whether developers who work alone are self-employed, or just work solo within a company.)

 

As for company size, the types of organizations that employ developers are spread pretty evenly between small companies with fewer than 10 employees, medium-sized ones and large enterprises, although companies with between 11 and 99 employees had the highest representation among developers surveyed.

 

Integrating payments

One of the more interesting questions on the survey was about how hard it is to integrate payments into an app. That may not be a task that developers think about until they sit down and actually do it, but given how many apps have to process payments today, payment integration has become an important part of coding.

 

On this topic, most developers said it was “somewhat easy” to integrate payments, but about 35 percent said it was somewhat difficult or very difficult.

 

Conclusion

Above are just some of the findings from Worldpay’s developer survey report. For full details and specific data points, as well as some interesting results involving developer preferences regarding cats, dogs and more, check out the report.

Businesses invest a lot of resources in getting consumers to click on ads and drawing visitors to websites or mobile apps. They create amazing product displays to make people like and engage with their product catalog. They even offer irresistible discounts to finally get their products added to the shopping cart.

 

But even if these efforts are successful in attracting clicks and visitors, they don’t necessarily lead to results. A common challenge is the issue of “cart abandonment,” which means potential customers abandon a website or app once they are in the middle of the process of selecting items or paying for them. On average, an online store loses 75%-83.6% of sales to cart abandonment.

 

cart abandonment at 75%

 

Why do customers abandon their digital carts? There could be lots of reasons, of course, but poor user interface or user experience are chief among them, which are both issues that developers can help address.

 

Toward that end, here’s a list of five tips for preventing cart abandonment by improving the mobile flow checkout for their apps.

 

1. Let users check out as a guest

Thirty percent of users abandon the cart if they’re asked to register upfront. Niche players face this challenge more than the Amazons of the world. Customers don't like registering unless it is tied to a benefit (say a coupon code). Sometimes, even existing customers don’t prefer signing in. This is especially true when they forget their passwords and have to go through the password reset flow. These are key reasons why cart abandonment rates are lower with sites that allow users to check out as a guest.

 

good mobile workflow checkout as guest

While some users might like to provide information to get personalized suggestions, others might not like spending time filling out registration forms. So, always give them three options: sign up, sign in, and check out as a guest. This should not be a problem with fulfillment, as you can always add email and contact number fields in the delivery information form.

2. Make data entry a breeze

Most people avoid signing up just because they are too lazy to enter their details. Even when you allow users to check out as a guest, they will have to fill out the delivery form. So keep the forms precise and less boring. You can create a great user experience if you can fill out some of the fields in the delivery form by requesting certain permissions. For example, by requesting access to a user’s Google+ profile, you can fill out the fields like first name, last name, email, etc. Getting access to the user’s device location will help you get fields like state, city, locality, etc, automatically filled. This way, you can dramatically reduce the time your users would otherwise have to spend on a frustrating data entry process.

 

good user workflow data entry

Avoid clearing all fields if there is an error in one (or several) fields. Shoppers get frustrated with having to re-enter the whole thing. Save all the valid information and highlight the invalid information along with an error message. Additionally, display error messages clearly and avoid using generic messages like “invalid information.” The form you get while signing up for a Google account is a great example of a good user interface (UI) design. The form tells you exactly what went wrong and how it should be corrected.

 

mobile workflow how to correct fields

 

3. Make customers feel secure about payments

Not having a particular type of card or mobile wallet should not stop customers from checking out. Give them a lot of payment options. In addition, some customers are concerned about the security of their credit cards. Their fears are sometimes justified by the increasing number of cyber attacks. So always display security badges and make users feel secure about their payment. If possible, provide a delivery (COD) option for customers who don't know enough about security badges and aren’t comfortable with the online world.

4.  Keep the user focused on the checkout

One mistake that most online stores make is promoting other products on their checkout pages. This makes room for a lot of distraction. Customers tend to navigate to other pages hunting for better and better deals. They eventually end up confused looking at the myriad of options. Buyer’s dilemma sets in and results in cart abandonment.

 

You should cross-sell your products, but the checkout page is just not the right platform. Amazon recommends other products on the product page itself, but with a checkbox. This way, the user can buy the recommended products without leaving the main product page.

 

good workflow checkout

 

Keep designs simple, remove unnecessary links, and encourage a closed promo code field. Once a customer has added a product to the cart, your only goal should be getting the product checked out.

5. Avoid lengthy checkout processes

Don’t make the checkout page too long. Avoid less necessary conventional steps like asking “Are you sure about the details entered?” Break up the checkout process into multiple steps and deploy one step per page. Have a prominent progress bar to guide users through the checkout process. The load time of your site directly affects user experience. Fifty-seven percent of visitors abandon their carts if the load time exceeds three seconds. The faster your pages load, the more products you will sell.

Conclusion

Forty-nine percent of people operate their phones using one hand. So design the user interface in such a way that the user can complete the checkout process using one thumb. Make sure that the design works for tablet users as well. Enrich your app with all possible luxuries, and make the checkout flow as convenient as possible. Ensure that customer assistance is readily available. Add an iconic CTA button to call customer support. And offer useful links to FAQs so that users will not have to look for solutions across the Web when they have a problem with checkout. A good user experience is created only when you really care about the comfort of your customer.

 

 

Worldpay hosted payment pages provide websites with a simple and secure way to integrate payments into a site without the additional overhead of PCI compliance and the benefit of access to a multitude of payment types.

 

In this article, we’re going to look at this solution and walk through some tips for troubleshooting when test payments fail. We’ll be using the C# example which is available on GitHub and offers users a demo application which they can configure to use with a test account. We’ll cover setting up a test account below (if you haven’t already set up an account).

 

Browser Requirements

 

The hosted payments solution is added to websites using an iframe or lightbox control. In this article, we’ll be referencing the iframe specifically, but the same applies to the lightbox as well. The solution also makes use of JavaScript, so you’ll want to ensure that the user's browser has JavaScript enabled.

 

If you’re using the demo application, and are unable to click on any of the buttons, this is a good indication that JavaScript is disabled for the site. Using the <noscript> tag is an excellent way to indicate to users that they need to enable JavaScript to checkout using your website.

 

<noscript>
    <style type="text/css">
        .pagecontainer {display:none;}
    </style>
    <div class="noscriptmsg">
        This website requires that Javascript is enabled.
    </div>
</noscript>

  Figure 1. HTML to Detect a Browser that Does Not Have JavaScript Enabled.

 

If you can navigate to the checkout page, but are unable to view the Payment iframe, then it is likely that you haven’t configured the account credentials, there is an error in the configuration, or there was a problem setting up the transaction. If you are using the example application, and view the page source, you may observe an error indicating that iframes are disabled. The disabled iframe message is the default message which is displayed if the page is unable to set up the transaction, or retrieve the iframe from the payment processor.

 

We’ll walk through each of these problems in detail and discuss symptoms and how to resolve them.

 

Setting Up a Test Account

 

Requests to the Hosted Payments Service need to have the following information included:

 

  • Account ID
  • Account Token
  • Acceptor ID
  • Application ID
  • Application Name
  • Application Version

 

Application Name and Version are required, but these fields are for you to add information about your application. The remaining values require you to sign up for a Worldpay test account. You can sign up for a test account here.

 

Figure 1. Creating a Worldpay Test Account

 

Validating Your Configuration

 

When you create your test account, you’ll receive an email similar to the one below that has all the required values for your new account. The email also contains test URLs for your test hosted payments and links to documentation for hosted payments and other services which you’ll use with your test account.

 

Figure 2. Email with Account Information for Worldpay Test Account.

 

If you’re using the C# example, the Web.config file in the root folder of the project contains the Account Configuration. Validate that you have configured all six elements in your project and that values match those for your test account. If Worldpay can’t verify your account, then the iframe cannot be displayed.

 

The Anatomy of a Transaction

 

A complete transaction is a series of steps, which begin before the customer is prompted to enter their information. The first call sets up the transaction. The TransactionSetup is a POST request which includes the account credentials, terminal information, style information for the iframe, and the return URL. The call is handled by the server to prevent account information from being exposed to the end user. Once the transaction is set up, the browser can request the iframe.

 

 

<?xml version="1.0"?>
<TransactionSetup xmlns="https://transaction.elementexpress.com">
  <Credentials>
    <AccountID>#####</AccountID>
    <AccountToken>#####</AccountToken>
    <AcceptorID>#####</AcceptorID>
  </Credentials>
  <Application>
    <ApplicationID>#####</ApplicationID>
    <ApplicationVersion>1.0</ApplicationVersion>
    <ApplicationName>HostedPayments.CSharp</ApplicationName>
  </Application>
  <Terminal>
    <TerminalID>01</TerminalID>
    <CardholderPresentCode>2</CardholderPresentCode>
    <CardInputCode>5</CardInputCode>
    <TerminalCapabilityCode>3</TerminalCapabilityCode>
    <TerminalEnvironmentCode>2</TerminalEnvironmentCode>
    <CardPresentCode>2</CardPresentCode>
    <MotoECICode>1</MotoECICode>
    <CVVPresenceCode>1</CVVPresenceCode>
  </Terminal>
  <Transaction>
    <TransactionAmount>6.55</TransactionAmount>
  </Transaction>
  <TransactionSetup>
    <TransactionSetupMethod>1</TransactionSetupMethod>
    <Embedded>1</Embedded>
    <AutoReturn>1</AutoReturn>
    <ReturnURL>http://localhost:51619/Home/Complete</ReturnURL>
    <CustomCss>body{margin-left: 50px; …}</CustomCss>
  </TransactionSetup>
</TransactionSetup>

Figure 3. XML Request to Set Up a Transaction

 

In response to the request above, the processor returns the following, which includes a transaction number. This number is used by the client or browser to request the iframe.

 

<?xml version="1.0"?>
<TransactionSetupResponse xmlns="https://transaction.elementexpress.com">
  <Response>
    <ExpressResponseCode>0</ExpressResponseCode>
    <ExpressResponseMessage>Success</ExpressResponseMessage>
    <ExpressTransactionDate>20181230</ExpressTransactionDate>
    <ExpressTransactionTime>162113</ExpressTransactionTime>
    <ExpressTransactionTimezone>UTC-06:00:00</ExpressTransactionTimezone>
    <Transaction>
      <TransactionSetupID>
A5EC4889-89870E7CEB97</TransactionSetupID>
    </Transaction>
    <PaymentAccount> 

      <TransactionSetupID>A5EC4889-89870E7CEB97</TransactionSetupID>
    </PaymentAccount>
    <TransactionSetup>
      <TransactionSetupID>
A5EC4889-89870E7CEB97</TransactionSetupID>
      <ValidationCode>068F65440B</ValidationCode>
    </TransactionSetup>
  </Response>
</TransactionSetupResponse>

Figure 4. XML Response with Transaction ID

 

If you enable debugging on your local server and step through the code, you should be able to see the response coming back from the processor. I was able to create a couple of different errors by changing aspects of the request I sent.

 

<?xml version="1.0"?>
<Response xmlns="https://transaction.elementexpress.com">
  <Response>
    <ExpressResponseCode>103</ExpressResponseCode>
    <ExpressResponseMessage>Invalid Request</ExpressResponseMessage>
  </Response>
</Response>

Figure 5. Example of a Response for an Invalid Request

 

In the case above, this was due to not setting the correct headers on the request. For XML requests to the payment processor, the required headers are:

 

  • Content-Type: text/xml
  • Accepts: text/xml

 

<?xml version="1.0"?>
<Response xmlns="https://transaction.elementexpress.com">
  <Response>
    <ExpressResponseCode>103</ExpressResponseCode>
    <ExpressResponseMessage>TargetNamespace required</ExpressResponseMessage>
  </Response>
</Response>

Figure 6. Another Example of a Response for an Invalid Request

 

In the case shown in Figure 6, the namespace was incorrectly set. The XML namespace is set on the parent element and should take the following format.

 

<TransactionSetup xmlns="https://transaction.elementexpress.com">

 

Troubleshooting Client Payment Submission Errors

 

The request from the iframe is synchronous and returns the results of the transaction, and redirects the browser on a successful transaction to the URL which you specified when you set up the transaction. The processor parses user information completeness and validity. Below are some of the results which appear in the browser for missing or invalid data.

 

Figure 7. Missing Information on the Payment Information Form

Figure 8. Invalid Card Information on the Payment Information Form

 

Additional Help

 

If you are still experiencing problems with your test payments, you can visit the Vantiv Developer Portal to see if other developers have experienced similar problems and posted their solutions. You can also reach out to a Worldpay representative here