New Spreedly Dashboard Boosts Successful Transactions

The new Spreedly Dashboard is here! It gives users tools to increase successful transactions.

You're building great buying experiences for your customers. And you want to support that experience with successful transactions. Spreedly gives you tools to monitor and troubleshoot transactions to increase success rates, and do more business.

Now, the new dashboard puts key Spreedly functionality at your fingertips. You and your team have even faster access to the data, insights, and tools you need to help boost successful transactions. Start your free trial now

What's New in the New Dashboard?

We listened closely to customer feedback, building it into the new release. We've centralized key management tools into a single tool, and we've only just started on our mission to build a powerful and practical dashboard for you. From one place, you can:

Monitor your Transactions

Right from the Spreedly Dashboard, you can monitor the execution of transactions. You can get insights into account usage, transaction volumes, success rates, and more. You also gain great visualizations of transaction success rates over time. That allows you to spot areas for areas for improvement and stay on top of your customer experience.

Plus, the Spreedly Dashboard lets you compare your transaction success and failure rates against Spreedly averages across multiple gateways. That gives you peace of mind about your account performance and lets you quickly address opportunities to boost your success rate.

The new dashboard makes it even easier to troubleshoot and debug your application. Simply select the environment you want to focus on in order to filter transactions. Then, when you click on a transaction, you're taken to key information about it -- like whether it succeeded and relevant error messages. You can even get quick access to any failed or successful transaction through a quick search function within the dashboard.

The Spreedly Dashboard features quick links to get to important Spreedly tools. The sidebar brings together links to access account insights, manage your account, view billing details, speak to support, monitor recent transactions, and review our detailed developer documentation. That makes it faster for you to access the Spreedly tools you use most often.

The new dashboard is live, and you can start now! With the new Spreedly Dashboard, you have a new, unified experience to help you do more business.

Get started by reading the Spreedly success article or access your dashboard now.

If you're an online merchant or e-commerce provider by now you know you should use an iFrame based payment form to minimize your PCI compliance burden. And, in general, you're in luck! Since PCI DSS 3.0 is almost two years old by now, most payment gateways and payment processors have iFrame-based payment forms available for use. 

However, all is not rosy in the payment form landscape. Just because your gateway offers a payment form that has "iFrame" somewhere in the description does not mean it fulfills the spirit of the PCI guidelines, nor does it mean it's the right choice for your business. 

Because Spreedly integrates to over a hundred separate payment gateways, we see a lot of payment form implementations and can offer a unique perspective for online merchants choosing the right iFrame payment form.

Before we dive in, keep in mind this is mainly a cautionary tale meant to reinforce that you, the e-commerce merchant, are responsible for choosing the tools that adhere to your stated level of PCI certification. Just because you use a gateway X, and that gateway X provides an iFrame payment form, doesn't mean your PCI assessor or the brands themselves will let you abdicate that decision. You're on the hook, so you need to be able to defend your position.

Below we discuss choosing an iFrame payment form across three different axes, starting with the most obvious – adherence to the PCI specification.

 

PCI Compliance

PCI compliance, which all online merchants must adhere and attest to, is a beast of certification. Vague guidelines, competing interpretations, and lots of misinformation make it really hard to know what's required of your business. Fortunately, a series of updates to the original version 3.0 (now at 3.2) and some

We now know, unequivocally, that to qualify for SAQ A
‚load all payment content from a PCI DSS compliant service provider‚Äù. This means the form fields that collect the credit card number and CVV, any accompanying javascript libraries, and the submission of the payment data itself, must both originate and return back to the payment provider itself. This might seem obvious, but in reality it's difficult to know if this is really what your provider is doing since there are often layers of abstraction between your use of the provider's client libraries and the actual representation in-browser.

We now know, unequivocally, that to qualify for SAQ A your iFrame payment form must load all payment content from a PCI DSS compliant service provider.

Here's an easy way to tell if your provider's iFrame form is adhering to this aspect of the PCI guidance.

1. In your browser, navigate to a page that utilizes the provider's iFrame payment form (this could be a demo site, or a known customer).

2. Using your browser's developer tools, inspect the credit card number field.

3. In the rendered document view that comes up in your browsers' developer tools, look to see if the credit card number HTML form element (usually an input field) is rendered within an iFrame (e.g. there's an iFrame anywhere in its parent hierarchy). This is what it looks like when the field is not contained within an iFrame, meaning that sensitive field is not served directly from your provider and you are exposed to additional PCI compliance burden (taken from a production site using a popular gateway's payment form):

‍

By contrast, this is what it looks like when a PCI-sensitive field like the credit card number is served directly from the payment provider within an iFrame:

This might seem like an arcane technical detail but don't dismiss it! It has a direct effect on your ability to self-assess using the 4 page SAQ A vs. the 40 page SAQ A-EP and it is your, not your payment gateways, responsibility to make the final PCI determination.

 

Brand Continuity

Ugly, unusable, downright hostile payment forms are not only death to your conversion rate ‚ they also have a particularly insidious effect on your brand. Not a day goes by without someone taking to their preferred social media channel to vent about what great inconvenience your site has caused them. Do you want this kind of shame retweeted and liked over 2,000 times for your brand?

As an online merchant, store, or e-commerce brand, it is your responsibility to craft the best experience for your users. Though this might take more time than just slapping your current payment provider's stock form on your site, the fact is that it's a commercially justified effort. Not only will your users have a delightful checkout experience, you will walk away with more $$ in your pocket from the non-trivial increase in checkout rates.

Things to look for in an iFrame payment form are the ability to customize both the look and feel of the form as well as the structure of the form itself. This often manifests as the ability to position the credit card number and CVV fields independent of one another and set custom CSS properties on these fields, even though they live inside your provider's iFrame. While a more complex implementation for the merchant, this results in a better checkout rates for online merchants and better brand experience for the customers.

 

Documentation

Old-school payment companies tend to be cut of a different cloth than modern technology or developer tooling companies. Large institutions can be secretive and protective of their technical documentation, which can meaningfully delay your integration effort. Thankfully, this divide is closing. But you should accept nothing less than publicly available integration guides, technical
documentation, and self-service test credentials.

Having documentation is very different from having good documentation. Your provider’s developer documentation should be clearly organized both by purpose (mobile payments, etc…) and product (iFrame form, etc…). Additionally, the API documentation should be very clearly separated from the general guides. Guides are good for walking developers new to the toolset through the features and tend to be prose-oriented. API docs are good for when you know what you’re looking for and just need to see the raw technical details. These are two very different purposes best served by two different structures.

 

iFrame Payment Form Comparisons

At Spreedly, it's our job to provide integrations to over a hundred payment gateways. As a result, we have a lot of relevant experience with iFrame payment forms. We have
as well. Let's look at how a few popular gateways' iFrame forms stack up by these characteristics:

Options

If your payment gateway provides a really clean iFrame payment form that adheres to all the points raised here, then lucky you! However, chances are if you're using any but the top 3-5 developer-oriented gateways, your iFrame payment form options will be lacking. What to do in that case? Switching payment gateways is always an option, but many times there are business reasons to keep your existing processor. 

That's where Spreedly comes into play. Spreedly modernizes your antiquated gateway. Spreedly's tooling, built by developers for developers as part of a modern payment stack, lets you integrate with the payment gateway of your choice.
I hope this guide was helpful. Please sign up for a free developer account at Spreedly if you're not happy with your gateways' tooling. You can also view the Spreedly iFrame documentation if you want a point of comparison.

*See the latest updates regarding iFrames here*

‍

Download the Payments Orchestration eBook Below