From Nicholas Zakas’ newsletter, on how he avoids JavaScript fatigue:

I don’t try to learn about every new thing that comes out. There’s a limited number of hours in the day and a limited amount of energy you can devote to any topic, so I choose not to learn about anything that I don’t think will be immediately useful to me. That doesn’t mean I completely ignore new things as they are released, but rather, I try to fit them into an existing mental model so I can talk about them intelligently. For instance, I haven’t built an application in Deno, but I know that Deno is a JavaScript runtime for building server-side applications, just like Node.js. So I put Deno in the same bucket as Node.js and know that when I need to learn more, there’s a point of comparison.

I too have used the “buckets” analogy. Please allow me to continue and overuse this metaphor.

I rarely try to learn anything just for the sake of it. I learn what I need to learn as whatever I’m working on demands it. But I try to know enough so that when I read tech news, I can place what I’m reading into mental buckets. Then I can, metaphorically, reach into those buckets when those topics come up. Plus, I can keep an eye on how full those buckets are. If I find myself putting a lot of stuff into one bucket, I might plunge in there and see what’s going on as there is clearly something in the water.

You’ll need to subscribe to the newsletter to get to the content.

Direct Link to Article — Permalink

---

The post JavaScript Fatigue appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Unless you’ve been hiding under a rock the last several years (and let’s face it, hiding under a rock sometimes feels like the right thing to do), you’ve probably heard of and likely used TypeScript. TypeScript is a syntactical superset of JavaScript that adds — as its name suggests — typing to the web’s favorite scripting language.

TypeScript is incredibly powerful, but is often difficult to read for beginners and carries the overhead of needing a compilation step before it can run in a browser due to the extra syntax that isn’t valid JavaScript. For many projects this isn’t a problem, but for others this might get in the way of getting work done. Fortunately the TypeScript team has enabled a way to type check vanilla JavaScript using JSDoc.

Setting up a new project

To get TypeScript up and running in a new project, you’ll need NodeJS and npm. Let’s start by creating a new project and running npm init. For the purposes of this article, we are going to be using VShttps://code.visualstudio.comCode as our code editor. Once everything is set up, we’ll need to install TypeScript:

npm i -D typescript

Once that install is done, we need to tell TypeScript what to do with our code, so let’s create a new file called tsconfig.json and add this:

{
  "compilerOptions": {
    "target": "esnext",
    "module": "esnext",
    "moduleResolution": "node",
    "lib": ["es2017", "dom"],
    "allowJs": true,
    "checkJs": true,
    "noEmit": true,
    "strict": false,
    "noImplicitThis": true,
    "alwaysStrict": true,
    "esModuleInterop": true
  },
  "include": [ "script", "test" ],
  "exclude": [ "node_modules" ]
}

For our purposes, the important lines of this config file are the allowJs and checkJs options, which are both set to true. These tell TypeScript that we want it to evaluate our JavaScript code. We’ve also told TypeScript to check all files inside of a /script directory, so let’s create that and a new file in it called index.js.

A simple example

Inside our newly-created JavaScript file, let’s make a simple addition function that takes two parameters and adds them together:

function add(x, y) {
  return x + y;
}

Fairly simple, right? add(4, 2) will return 6, but because JavaScript is dynamically-typed you could also call add with a string and a number and get some potentially unexpected results:

add('4', 2); // returns '42'

That’s less than ideal. Fortunately, we can add some JSDoc annotations to our function to tell users how we expect it to work:

/**
 * Add two numbers together
 * @param {number} x
 * @param {number} y
 * @return {number}
 */
function add(x, y) {
  return x + y;
}

We’ve changed nothing about our code; we’ve simply added a comment to tell users how the function is meant to be used and what value should be expected to return. We’ve done this by utilizing JSDoc’s @param and @return annotations with types set in curly braces ({}).

Trying to run our incorrect snippet from before throws an error in VS Code:

In the example above, TypeScript is reading our comment and checking it for us. In actual TypeScript, our function now is equivalent of writing:

/**
 * Add two numbers together
 */
function add(x: number, y: number): number {
  return x + y;
}

Just like we used the number type, we have access to dozens of built-in types with JSDoc, including string, object, Array as well as plenty of others, like HTMLElement, MutationRecord and more.

One added benefit of using JSDoc annotations over TypeScript’s proprietary syntax is that it provides developers an opportunity to provide additional metadata around arguments or type definitions by providing those inline (hopefully encouraging positive habits of self-documenting our code).

We can also tell TypeScript that instances of certain objects might have expectations. A WeakMap, for instance, is a built-in JavaScript object that creates a mapping between any object and any other piece of data. This second piece of data can be anything by default, but if we want our WeakMap instance to only take a string as the value, we can tell TypeScript what we want:

/** @type {WeakMap<object, string} */
const metadata = new WeakMap();


const object = {};
const otherObject = {};


metadata.set(object, 42);
metadata.set(otherObject, 'Hello world');

This throws an error when we try to set our data to 42 because it is not a string.

Defining our own types

Just like TypeScript, JSDoc allows us to define and work with our own types. Let’s create a new type called Person that has name, age and hobby properties. Here’s how that looks in TypeScript:

interface Person {
  name: string;
  age: number;
  hobby?: string;
}

In JSDoc, our type would be the following:

/**
 * @typedef Person
 * @property {string} name - The person's name
 * @property {number} age - The person's age
 * @property {string} [hobby] - An optional hobby
 */

We can use the @typedef tag to define our type’s name. Let’s define an interface called Person with required name (a string)) and age (a number) properties, plus a third, optional property called hobby (a string). To define these properties, we use @property (or the shorthand @prop key) inside our comment.

When we choose to apply the Person type to a new object using the @type comment, we get type checking and autocomplete when writing our code. Not only that, we’ll also be told when our object doesn’t adhere to the contract we’ve defined in our file:

Now, completing the object will clear the error:

Sometimes, however, we don’t want a full-fledged object for a type. For example, we might want to provide a limited set of possible options. In this case, we can take advantage of something called a union type:

/**
 * @typedef {'cat'|'dog'|'fish'} Pet
 */


/**
 * @typedef Person
 * @property {string} name - The person's name
 * @property {number} age - The person's age
 * @property {string} [hobby] - An optional hobby
 * @property {Pet} [pet] - The person's pet
 */

In this example, we have defined a union type called Pet that can be any of the possible options of 'cat', 'dog' or 'fish'. Any other animals in our area are not allowed as pets, so if caleb above tried to adopt a 'kangaroo' into his household, we would get an error:

/** @type {Person} */
const caleb = {
  name: 'Caleb Williams',
  age: 33,
  hobby: 'Running',
  pet: 'kangaroo'
};

This same technique can be utilized to mix various types in a function:

/**
 * @typedef {'lizard'|'bird'|'spider'} ExoticPet
 */


/**
 * @typedef Person
 * @property {string} name - The person's name
 * @property {number} age - The person's age
 * @property {string} [hobby] - An optional hobby
 * @property {Pet|ExoticPet} [pet] - The person's pet
 */

Now our person type can have either a Pet or an ExoticPet.

Working with generics

There could be times when we don’t want hard and fast types, but a little more flexibility while still writing consistent, strongly-typed code. Enter generic types. The classic example of a generic function is the identity function, which takes an argument and returns it back to the user. In TypeScript, that looks like this:

function identity<T>(target: T): T {
  return target;
}

Here, we are defining a new generic type (T) and telling the computer and our users that the function will return a value that shares a type with whatever the argument target is. This way, we can still pass in a number or a string or an HTMLElement and have the assurance that the returned value is also of that same type.

The same thing is possible using the JSDoc notation using the @template annotation:

/**
 * @template T
 * @param {T} target
 * @return {T}
 */
function identity(target) {
  return x;
}

Generics are a complex topic, but for more detailed documentation on how to utilize them in JSDoc, including examples, you can read the Google Closure Compiler page on the topic.

Type casting

While strong typing is often very helpful, you may find that TypeScript’s built-in expectations don’t quite work for your use case. In that sort of instance, we might need to cast an object to a new type. One instance of when this might be necessary is when working with event listeners.

In TypeScript, all event listeners take a function as a callback where the first argument is an object of type Event, which has a property, target, that is an EventTarget. This is the correct type per the DOM standard, but oftentimes the bit of information we want out of the event’s target doesn’t exist on EventTarget — such as the value property that exists on HTMLInputElement.prototype. That makes the following code invalid:

document.querySelector('input').addEventListener(event => {
  console.log(event.target.value);
};

TypeScript will complain that the property value doesn’t exist on EventTarget even though we, as developers, know fully well that an does have a value.

In order for us to tell TypeScript that we know event.target will be an HTMLInputElement, we must cast the object’s type:

document.getElementById('input').addEventListener('input', event => {
  console.log(/** @type {HTMLInputElement} */(event.target).value);
});

Wrapping event.target in parenthesis will set it apart from the call to value. Adding the type before the parenthesis will tell TypeScript we mean that the event.target is something different than what it ordinarily expects.

And if a particular object is being problematic, we can always tell TypeScript an object is @type {any} to ignore error messages, although this is generally considered bad practice depsite being useful in a pinch.

Wrapping up

TypeScript is an incredibly powerful tool that many developers are using to streamline their workflow around consistent code standards. While most applications will utilize the built-in compiler, some projects might decide that the extra syntax that TypeScript provides gets in the way. Or perhaps they just feel more comfortable sticking to standards rather than being tied to an expanded syntax. In those cases, developers can still get the benefits of utilizing TypeScript’s type system even while writing vanilla JavaScript.

---

The post TypeScript, Minus TypeScript appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Importing data is a common pain-point for engineering teams. Whether its importing CRM data, inventory SKUs, or customer details, importing data into various applications and building a solution for this is a frustrating experience nearly every engineer can relate to. Data import, as a critical product experience is a huge headache. It reduces the time to value for customers, strains internal resources, and takes valuable development cycles away from developing key, differentiating product features.

Data importers, specifically CSV importers, haven’t been treated as key product features within the software, and customer experience. As a result, engineers tend to dedicate an exorbitant amount of effort creating less-than-ideal solutions for customers to successfully import their data.

In this article, we’ll address the current problems with importing data and discuss a few key product features that are necessary to consider if you’re faced with a decision to build an in-house solution.

Importing data is typically frustrating for anyone involved at a data-led company. Simply put, there has never been a standard for importing customer data. Until now, teams have deferred to CSV templates, lengthy documentation, video tutorials, or buggy in-house solutions to allow users the ability to import spreadsheets. Companies trying to import CSV data can run into a variety of issues such as:

• Fragmented data: With no standard way to import data, we get emails going back and forth with attached spreadsheets that are manually imported. As spreadsheets get passed around, there are obvious version control challenges. Who made this change? Why don’t these numbers add up as they did in the original spreadsheet? Why are we emailing spreadsheets containing sensitive data?
• Improper formatting: CSV import errors frequently occur when formatting isn’t done correctly. As a result, companies often rely on internal developer resources to properly clean and format data on behalf of the client — a process that can take hours per customer, and may lead to churn anyway. This includes correcting dates or splitting fields that need to be healed prior to importing.
• Encoding errors: There are plenty of instances where a spreadsheet can’t be imported when it’s not improperly encoded. For example, a company may need a file to be saved with UTF-8 encoding (the encoding typically preferred for email and web pages) in order to then be uploaded properly to their platform. Incorrect encoding can result in a lengthy chain of communication where the customer is burdened with correcting and re-importing their data.
• Data normalization: A lack of data normalization results in data redundancy and a never-ending string of data quality problems that make customer onboarding particularly challenging. One example includes formatting email addresses, which are typically imported into a database, or checking value uniqueness, which can result in a heavy load on engineers to get the validation working correctly.

Remember building your first CSV importer?

When it comes down to creating a custom-built data importer, there are a few critical features that you should include to help improve the user experience. (One caveat – building a data importer can be time-consuming not only to create but also maintain – it’s easy to ensure your company has adequate engineering bandwidth when first creating a solution, but what about maintenance in 3, 6, or 12 months?)

Data mapping

Mapping or column-matching (they are often used interchangeably) is an essential requirement for a data importer as the file import will typically fail without it. An example is configuring your data model to accept contact-level data. If one of the required fields is “address” and the customer who is trying to import data chooses a spreadsheet where the field is labeled “mailing address,” the import will fail because “mailing address” doesn’t correlate with “address” in a back-end system. This is typically ‘solved’ by providing a pre-built CSV template for customers, who then have to manipulate their data, effectively increasing time-to-value during a product experience. Data mapping needs to be included in the custom-built product as a key feature to retain data quality and improve the customer data onboarding experience.

Data validation

Data validation, which checks if the data matches an expected format or value, is another critical feature to include in a custom data importer. Data validation is all about ensuring the data is accurate and is specific to your required data model. For example, if special characters can’t be used within a certain template, error messages can appear during the import stage. Having spreadsheets with hundreds of rows containing validation errors results in a nightmare for customers, as they’ll have to fix these issues themselves, or your team, which will spend hours on end cleaning data. Automatic data validators allow for streamlining of healing incoming data without the need for a manual review.

Data parsing

Data parsing is the process of taking an aggregation of information (in a spreadsheet) and breaking it into discrete parts. It’s the separation of data. In a custom-built data importer, a data parsing feature should not only have the ability to go from a file to an array of discrete data but also streamline the process for customers.

Data transformation

Data transformation means making changes to imported data as it’s flowing into your system to meet an expected or desired value. Rather than sending data back to users with an error message for them to fix, data transformation can make small, systematic tweaks so that the users’ data is more usable in your backend. For example, when transferring a task list, prioritization data could be transformed into a different value, such as numbers instead of labels.

We’ve baked all of the above features into Portal, our flagship CSV importer at Flatfile. Now that we’ve reviewed some of the must-have features of a data importer, the next obvious question for an engineer building an in-house importer is typically… should they?

Engineering teams that are taking on this task typically use custom or open source solutions, which may not adhere to specific use-cases. Building a comprehensive data importer also brings UX challenges when building a UI and maintaining application code to handle data parsing, normalization, and mapping. This is prior to considering how customer data requirements may change in future months and the ramifications of maintaining a custom-built solution.

Companies facing data import challenges are now considering integrating a pre-built data importer such as Flatfile Portal. We’ve built Portal to be the elegant import button for web apps. With just a few lines of JavaScript, Portal can be implemented alongside any data model and validation ruleset, typically in a few hours. Engineers no longer need to dedicate hours cleaning up and formatting data, nor do they need to custom build a data importer (unless they want to!). With Flatfile, engineers can focus on creating product-differentiating features, rather than work on solving spreadsheet imports.

Importing data is wrought with challenges and there are several critical features necessary to include when building a data importer. The alternative to a custom-built solution is to look for a pre-built data importer such as Portal.

Flatfile’s mission is to remove barriers between humans and data. With AI-assisted data onboarding, they eliminate repetitive work and make B2B data transactions fast, intuitive, and error-free. Flatfile automatically learns how imported data should be structured and cleaned, enabling customers and teams to spend more time using their data instead of fixing it. Flatfile has transformed over 300 million rows of data for companies like ClickUp, Blackbaud, Benevity, and Toast. To learn more about Flatfile’s products, Portal and Concierge, visit flatfile.io.

---

The post Building Custom Data Importers: What Engineers Need to Know appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

A sale isn’t a sale until money changes hands. To get in on the $601.7 billion (and growing) of retail purchases that occur over the internet, your e-commerce business needs to accept payments online.

But a site’s payment system is more than just a matter of survival. A better checkout experience can also help your business grow.

In the e-commerce industry, where cart abandonment rates remain stuck in the 70 percent range, a smooth, intuitive payment experience is crucial. This guide will help you provide that experience. E-commerce experts and payment tech gurus will explain exactly how to accept payments online and which strategies can help entice visitors to cross the finish line.

Feel free to browse the table of contents and skip ahead. If you’re new to the topic, here are some of the key terms you’ll see mentioned throughout:

• A payment gateway is a software package that connects your website to payment networks. Gateway providers invest heavily in digital security measures, limiting risk for site operators and their customers.
• Merchant accounts are specialized bank services that facilitate credit and debit card payments. A merchant account holds funds until they’re fully authenticated and cleared to be transferred into a seller’s business account. Many payment gateways provide merchant accounts for their users, simplifying payment processing for sellers.
• Payment card is a catch-all term for the various types of cards buyers use to make payments, including credit, debit, prepaid, and charge cards. (Yes, they’re different, but don’t worry about the distinction just yet.)
• Payment methods refer to the particular financial instrument a customer uses to transfer funds. Credit cards, e-checks, ACH transfers, and digital wallets are all distinct payment methods.
• Payment processors are companies that submit transactions electronically on behalf of sellers. They provide the connection to credit card networks operated by card providers, while the payment gateway connects an online store to payment processors.

This guide speaks largely to online sellers, but the payment strategies we cover aren’t just necessary fuel for e-commerce. Nonprofits, B2B service providers, SaaS companies, and others need to provide streamlined and secure ways to send funds through the internet. In short, if you want to collect payments online, this guide is for you.

Chapter synopsis

• Chapter 1: Introduction.
• Chapter 2: Online payment gateways. For most online businesses, setting up a payment gateway will be your introduction to collecting payments digitally. Learn about the top gateways on the market and how to decide which options are right for you.
• Chapter 3: Online payment methods. There’s more to online payments than credit cards. Find out which payment methods are available — and why it’s important to provide your customers’ favorites.
• Chapter 4: Nonprofits and online payments. Nonprofits can boost donations and sell more merchandise when they process transactions online. Here’s what you need to know to surpass your collection goals through digital payments.
• Chapter 5: Online payments and security. Financial security is a prerequisite for successful online payments. This chapter describes the security infrastructure that protects your users’ financial information.
• Chapter 6: Collecting payments with online forms. Simplify the payment experience by integrating it into existing online forms. In Chapter 6, we explain all the ways this is possible.
• Chapter 7: How to build an online payment form. Now that you know the basics of online payments, it’s time to build your first order form. Here’s what you need to know.

We recommend bookmarking this guide for future reference. There’s a lot to learn about online payment systems, and you never know when you’ll want to try a new approach or build on an existing one.

Online payment gateways

A payment gateway is the technology that allows sellers to process transactions involving credit cards, debit cards, and alternative payments like e-checks and digital wallets. The term “payment gateway” also includes physical tools like credit card terminals, so experts differentiate between payment gateways and online payment gateways.

In this guide, we’ll focus on online payment gateways, which provide the software e-commerce merchants need to accept payments through their websites.

How online payment gateways handle a transaction

How does an online payment gateway work? Here’s the process a gateway uses to help a seller accept credit card payments online:

1. A shopper selects an item to purchase and follows the prompts to the payment stage, providing a credit card number and authorizing information.
2. The gateway’s software encrypts transaction data and securely transfers it to the payment processor, typically a bank-designated “acquirer.”
3. The acquiring bank routes the payment request (again with strict data security) to card processing networks. Major credit card companies operate these networks; common examples are Visa and Mastercard.
4. The card network verifies the card information, adding another fraud check to the process. Then it submits the payment request to the card-issuing bank.
5. The issuing bank completes another fraud check and verifies that the customer has available funds for the purchase. Then it either accepts or declines the request and sends that decision back to the payment gateway.
6. The gateway informs the buyer and the seller of the results. If the payment is accepted, the banks involved settle the payment, meaning they send the money from the buyer to the seller.

This entire process, right up to the settlement, is nearly instant. (Settlements, on the other hand, can take a few days.) The gateway acts as a connection between your customers, your site, and the payment networks that make digital fund transfers possible.

While online payment gateways allow sellers to accept credit card payments through their sites, payment cards aren’t the only method customers will use to buy your products.

Usage of digital wallets — software that stores funds in a secured electronic account (think Apple Pay and PayPal) — rose by 30 percent between 2017 and 2019, potentially reducing consumer dependence on traditional banks. And for B2B transactions, ACH payments remain a favorite, thanks to low fees and lack of spending limits that restrict credit card use.

We’ll explore alternative payment methods in Chapter 2, but as you compare payment gateway providers, be sure your top choices can handle the payment methods your customers prefer.

Four factors to consider when choosing an online payment gateway

Which gateway is right for you? That depends on a range of factors, including customer preference, ideal payment methods, user experience, and more. To get started, consider the following four components of major payment gateways.

1. Onsite vs offsite (hosted) checkout

Ronen Amit, senior e-commerce strategist and founder of SellerAct, says there are two options for gateway setup.

“The first way is probably the simplest,” Amit explains. “When you [the buyer] hit the button to pay, you will be redirected to another website, which is secured. After the payment is completed, you will be redirected back to the original website, usually to a thank-you page.” These types of gateways are also called “hosted payment pages.”

The second setup doesn’t redirect buyers to the gateway’s website. Instead, the user appears to enter their payment information directly into the seller’s site. What’s actually happening is a little more complicated, says Duston Sholtes, COO of e-commerce developer Blue Stingray.

He uses PayPal as an example of a gateway provider that offers both redirects and an on-the-page experience for buyers. “In one option, PayPal actually takes the user to their site,” Sholtes says. “But they also offer what’s called an in-context experience, where the site uses JavaScript to pull in the payment form from the PayPal website, so customers don’t have to leave the website they’re on.”

In general, redirects at the payment stage can be risky. “You have to understand that your user will be redirected to another website, and you might lose control over some of the process,” Amit says. Redirects during payment can also make shoppers nervous, contributing to more cart abandonment.

The faster implementation may make hosted payment pages best for beginners. If you have the resources, however, look for a gateway that offers an in-context payment experience.

2. Mobile-friendly design

By 2021, more than half of all online purchases in the U.S. will take place on mobile platforms. If your payment gateway offers a poor mobile experience, you’re limiting your customer base considerably.

3. Support for multiple payment methods

Payment gateways accept varying combinations of payment methods. The more your site can accept, the better.

“Make sure you cater to the 56 percent of users who want multiple payment options,” says Travis McKnight of digital marketing agency Portent. “If you’re an e-commerce site, I recommend including Amazon Pay, Apple Pay, Google Pay, and PayPal alongside the standard credit card options like Visa and Mastercard. If you’re a B2B website, I advise you to check with your sales team to discover how most customers want to pay.”

4. Fee schedules that work for your business model

Some payment gateways charge a monthly fee as well as per-transaction rates. Others only get paid when you do. Some per-transaction rates are fixed at, say, 10 cents each; others charge a percentage of the payment price.

Some gateways include customization out of the box, while others charge for advanced features. Compare these details to find the one that works best for your business.

Keep these factors in mind as you research competing gateway providers. Here’s a list of them to get you started.

Major payment gateway providers

Payment gateways are the software products themselves, but payment gateway providers are the companies that make those particular solutions. So which payment gateway provider should you choose? Here’s a short list of some of the major payment gateway providers on the market:

• Authorize.Net
• PayPal
• Square
• Stripe
• FIS
• BlueSnap
• Braintree
• First Data
• WePay

Many e-commerce platforms pre-integrate these and other payment gateways into their systems, simplifying the setup process. If you build a Shopify website, for instance, enabling your gateways could be as simple as choosing from a list. Other website platforms may require you to integrate your choice of payment gateways on your own.

Setting up an online payment gateway will allow you, the merchant, to start accepting online payments, but what’s the experience like from the buyer’s perspective? Let’s look at some of the major payment methods today’s consumers use to pay for goods and services online.

Online payment methods

Consumer preferences for payment methods are always changing, as trends in both online and offline payments demonstrate. As of 2018, paper checks were out, having fallen to just 5 percent of all U.S. payments per month, and debit cards were in, surpassing cash as the most frequently used financial instrument for the first time.

E-commerce providers benefit from following these trends. Online payments are major drivers of the changes, so e-commerce sellers who can give customers their favorite ways to pay will see fewer cart abandonments and more repeat business.

Below are some of the top ways to accept payments online in the current digital ecosystem. Staying on top of this information — and the ways your existing customers prefer to pay — will help you create a better checkout experience.

Digital wallets

An up-and-coming payment method, digital wallets store customers’ account numbers and allow them to send and receive money online. PayPal, Apple Pay, Android Pay, Alipay, and WeChat Pay are all digital wallets being used today, and their popularity is growing worldwide.

Digital wallets are now the leading payment method for online transactions globally, representing 42 percent of all internet-based payments in 2019, according to Worldpay’s 2020 Global Payments Report.

In China, more than 70 percent of all online transactions relied on a digital wallet. By way of comparison, that figure stood at 25 percent in Germany, 32 percent in India, and 24 percent in the United States — but those numbers are likely to grow, according to Worldpay’s projections.

If you plan to operate on a global scale, you should choose a payment gateway that accepts leading “Pay” apps: Amazon Pay, Samsung Pay, and Google Pay, in addition to those listed above.

Credit cards, debit cards, and other payment cards

Taken together, payment cards are the second most used payment method in the global e-commerce industry. Payment cards include credit and debit cards, as well as more obscure options like charge and prepaid cards.

Credit cards are the most popular form of card-based payment, representing 24.2 percent of global online payments in 2019. Debit cards came in at a distant second, with just 10.6 percent of transactions.

Most payment gateways can access popular card networks like Visa and Mastercard. These payment methods are enough to get started, but as your business grows, you may find that limiting your customers to cards increases cart-abandonment rates.

E-checks and ACH payments

Online ACH payments, including e-checks, grew by 6.7 billion transactions in 2019 alone. These payment types are still growing online, and merchants often have questions about them. Let’s clarify the difference between ACH and e-checks.

What is an e-check?

E-checks are the digital equivalent of paper checks. They identify specific banks and bank accounts and provide authorization for the recipient to draw funds from the check writer.

What is an ACH payment?

An ACH payment is a funds transfer that takes place via the ACH Network, a centralized system that facilitates direct account-to-account transactions. ACH transactions typically charge lower processing fees than credit card networks. An e-check is a type of ACH payment — but not the only type.

Most U.S.-based online utility bill-paying services, whether they’re operated by banks or utility providers, use the ACH Network; many private-sector recurring billing systems do, too. If your company relies on recurring payments or conducts high-value B2B business, choose a payment gateway that allows you to accept ACH payments.

Local payment methods

Depending on where you do business, you may need to find payment gateways that cater to local preferences, such as online/cash hybrids and bank transfers.

That’s the case in Brazil, for instance, where a cash-to-digital system called boleto bancário accounts for a full quarter of all online payments. In this system, at the point of payment, sellers provide a prefilled boleto bancário payment slip, similar to a printable bill.

“You take the bill to the bank, you pay for it, the bank scans it, and the payment is processed,” explains Amit. “It’s an online-and-offline combination of payments.”

Other unique local payment methods include SEPA Direct Debit in Europe, iDEAL in the Netherlands, and Giropay in Germany.

Cryptocurrencies

Cryptocurrencies like Bitcoin, Ethereum, and Facebook’s embattled Libra may seem like obscure novelties, but people do use cryptocurrencies to make purchases online. According to the Worldpay Global Payments Report, this payment method currently makes up less than 1 percent of the world’s total e-commerce transactions — but if your customers show a preference for blockchain-based digital money, it’s smart to find a gateway that will allow you to accept cryptocurrency.

As our preference for the word “customers” implies, we’ve been focusing largely on e-commerce in this guide. But nonprofit organizations need ways to accept payments online, as well. The process of accepting those payments may look a little different once you enter the charitable giving space.

Nonprofits and online payments

Nonprofits have a lot to gain from online payments. Take Sacramento-based NPR member station Capital Public Radio. In 2017, 57 percent of the nonprofit’s yearly donations came from a sustaining membership program largely processed through the ACH online payments network.

Capital Public Radio’s experience is no outlier, either. Online giving to nonprofits increased by 12.1 percent in 2019 alone. And sustaining memberships aren’t the only reason nonprofits should accept funds through the internet. Other opportunities associated with online payments in the nonprofit industry include

• Donations. According to the 2018 Trends in Giving Report, 54 percent of donors prefer to make their donations online. Your supporters are accustomed to paying online and are often more likely to click a link than to mail a check.
• Merchandise sales. Nonprofits aren’t in business to make sales, but that doesn’t mean they can’t take advantage of opportunities to sell. One well-known example is the Girl Scouts. Proceeds from annual cookie sales go to local Girl Scout councils; one in North Carolina gets up to 70 percent of its yearly operating budget from fall cookie revenues. Taking your merchandise sales online can expose you to a much broader audience and raise revenue.
• Ticket sales. Fundraising events are a cornerstone of nonprofit fundraising, and selling those tickets online can tap into a growing consumer preference. Between 2014 and 2019, the online event ticket sales industry grew by an average of 8.3 percent each year, leading to a total revenue value of $10 billion in 2019.
• Dues collection. Does your nonprofit collect recurring dues payments? If so, consider setting up a recurring payments structure through the ACH Network or another processor.

The process of setting up online payments for nonprofits mirrors that of e-commerce merchants. You’ll need a payment gateway that can process your supporters’ favorite ways to pay online. Several nonprofit-focused payment services are available, or you can go with an e-commerce juggernaut like PayPal, which facilitated $7.3 billion worth of donations in 2016. You can even integrate PayPal into your online forms to support online giving and email fundraising.

Some nonprofit operators, and their for-profit counterparts, worry about security for online payments — and that’s a valid concern. The good news is that today’s online payment infrastructure has well-developed security technologies built in. Here’s how online payment systems keep payment information safe from bad actors.

Online payments and security

At a time when more than half of U.S. consumers “strongly distrust” online security, keeping payment information safe — and sharing your security efforts with customers — is critical for the success of every e-commerce operation. In some regions, business owners must comply with specific regulations to accept online payments legally.

In this chapter, we’ll cover some of those laws and regulations. We’ll also discuss a common security practice that site operators can use to improve online security for payment systems.

Online payment security standards and laws

The regulations that govern payment security differ from place to place. As of now, there’s no universal mandate for securing payments over the internet — although that doesn’t reduce the importance of strong payment security, if only to retain customers.

If you have customers in the European Union, or if you’re located there yourself, the key regulation is PSD2, “Revised rules for payment services in the EU.” The term PSD2 is shorthand for Payment Services Directive 2. The directive went into full effect on September 14, 2019, at which point online businesses had to be in full compliance.

The PSD2 standards are designed to strengthen protections for financial data transmitted online. One of the biggest changes under PSD2 is the requirement for “strong customer authentication,” or SCA. Specifically, SCA requires the use of at least two of the three elements below to assure the validity of an online payment transaction:

• A detail that only the user would know. Factors like PINs and passwords fall under this knowledge-based authentication.
• Something only the user would possess. That could be a mobile phone, as in the case of multifactor authentication strategies that involve texting a single-use code to the user’s phone on each request.
• Biometric or body-based identifiers. Currently, these include technologies like touch ID and facial recognition.

The main safety standard outside the EU is PCI DSS, a set of security requirements maintained by the Payment Card Industry Security Standards Council.

The PCI DSS affects every entity involved in online payments, including merchants, processors, and gateway providers. Global credit card processing networks typically require some level of compliance with PCI DSS, which means even EU-based businesses that meet PSD2 standards should comply.

Broadly, PCI DSS introduces six distinct requirements outlined in the Requirements and Security Assessment Procedures:

1. Build and maintain a secure network and systems
2. Protect cardholder data
3. Maintain a vulnerability management program
4. Implement strong access control measures
5. Regularly monitor and test networks
6. Maintain an information security policy

While meeting these requirements may seem daunting, you don’t have to handle these challenges alone. Often, the best way to ensure PCI compliance is to partner with payment gateways and processors who meet these six obligations consistently.

SSL certificates for payment security

If you’re planning to start an e-commerce site — or want to make your existing payments infrastructure more secure — start by asking your payment gateway(s) about PCI DSS compliance and other fraud prevention services they employ. Don’t forget to inform your customers about these efforts on your site.

There’s one important step site owners can take to both improve security and improve confidence for your customers: Obtain an SSL/TLS certificate to prove to visitors that your site encrypts sensitive data before transmitting it over the internet.

The terms SSL and TLS stand for Secure Sockets Layer and Transport Layer Security. While TLS is the latest protocol, SSL remains a more familiar term. These certificates are available from web hosting services. Ensure that your provider includes SSL/TLS certificates before signing any agreements.

A browser that doesn’t have an SSL/TLS certificate may not be able to accept payments. “Most browsers today alert you if there’s any kind of information that is transferred insecurely,” says Amit. “Sometimes they won’t even allow entry into that page.”

Payment security beyond the e-commerce industry

While digital security is essential for the growth of e-commerce, anyone who accepts payments online needs to address the issue. As we covered in Chapter 3, nonprofits and other non-business organizations can benefit greatly from online payments. Peer-to-peer payments are also on the rise, with 44 percent of respondents to a 2018 survey saying they had used them, and 37 percent saying they hadn’t.

Businesses of all types can also use online payment systems within their companies. You might collect online payments internally to cover shared expenses for company events, for instance. Find out how to easily set up safe, secure intra-organization payment forms.

This type of payment form isn’t the only one that JotForm provides. Let’s look at the role JotForm can play in the structure of your payments, regardless of your goals.

Collecting payments with online forms

The payment form is a crucial step in the sales process. Form design and usability have a direct impact on conversion rates. Luckily, it doesn’t take a team of web developers to create a user-friendly payment form.

JotForm makes the form-building process easy with an intuitive drag-and-drop interface and exactly zero coding experience required. Advanced users can always edit in HTML if they prefer.

JotForm has been helping site owners around the world build payment forms for more than 12 years. In fact, payment forms are one of the top reasons our customers reach out to us. You can even add payment fields to existing forms, giving your audience one-stop payments access through the most popular pages on your site — even on social media.

All you have to do is add a widget through our intuitive interface and provide the relevant details.

JotForm’s Form Builder makes it easy to implement payment systems into online forms, each of which provides users with

• Industry-leading security. When your customers submit payment information through JotForm, that data is protected by the most stringent security protocols in the industry. JotForm servers never store user payment data, and all data remains secured by 256-bit SSL encryption on its way to your gateway provider. JotForm is also PCI DSS compliant, with a PCI Service Provider Level 1 certificate. Security certificates are available on request — simply talk to the JotForm support team to learn more.
• Payment versatility. Do you collect recurring payments? Do you need to make auto calculations based on users’ choices? JotForm provides simple access to payment structures of all types, from a single product purchase to ongoing ACH deductions.
• Integration with your most successful channels. Add a payment form to your website or allow secure payments directly through your Facebook page. Learn more about JotForm for Facebook payments.
• No commissions or added fees. JotForm doesn’t collect fees for the payments you accept. We also don’t collect commissions or add any costs to your payment gateway’s transaction fees.
• Customized payment experience without coding. Build a form with a payment integration to collect customer information and payments at the same time. Because JotForm is highly customizable, you can create your own payment experience without hiring a development team.

To be clear, JotForm doesn’t operate a payment gateway. We simply make it easier for your customers to access the gateways you already work with through our integrations with payment gateways. And odds are, if you use a payment gateway, JotForm can integrate with it.

Payment gateway integrations with JotForm

JotForm provides simple integrations with leading gateway providers to create quick, hassle-free payment forms. And this is worth saying again: We don’t charge any additional fees when you accept payment through a form. (You’ll need an account with your preferred payment gateway before adding it to your form, of course.)

A few examples of the payment integrations available through JotForm include

• PayPal. Collect payments with any of PayPal’s leading payment services, including PayPal Checkout, PayPal Pro, and PayPal Invoicing.
• Stripe. Stripe is a developer-friendly gateway with a simple per-transaction pricing structure. A parallel service, Stripe ACH, allows users to accept e-checks and other ACH payments. Learn how to add Stripe and Stripe ACH to your form.
• Square. In the last quarter of 2019, Square’s payments volume surpassed $28 billion. The platform allows both single-instance and recurring payments. Learn how to add a Square integration to your form.
• Moneris. In Canada, Moneris is the top payment processor for both online and in-person transactions. Learn how to add Moneris to your form.

These are just a few of the payment gateway integrations available through JotForm. Our integration options are always growing, and all of the most popular payment services are available through our platform. Search the complete list of payment integrations available on JotForm.
If you have questions, resources are always available. Read our user guide on payment form integrations or contact our support team directly. If you’re ready to build your first payment form now, keep reading.

How to build an online payment form

Building your first online payment form is simple with JotForm’s drag-and-drop Form Builder. To start, you’ll need to have an account already in place with your preferred payment gateway. After that, you’re ready to use a payment form.

There are lots of payment options available from JotForm, and the list is always growing. If you have questions or don’t see something you need, check out our user guides or reach out to our customer support team. One of the following form types works for most businesses:

• Order forms. Use order forms to sell products, collect donations, register visitors for paid events, and more. Start your own publishing wing by selling white papers, e-books, and reports in PDF format. Take advantage of our templates or build your own forms. List a single product or many different products, with or without custom modifications for each item. Learn more.
• Recurring payments. Recurring payment forms are perfect for collecting payments on a regular, repeat basis for services or publications; charging monthly dues for organization memberships; or giving nonprofit supporters the option of making recurring donations. No matter what the recurring payment is for, you can set up an order form through JotForm that simplifies the process. Learn more.
• Purchase orders. Actual payments for many B2B transactions are handled through company accounting departments. In this scenario, you don’t make a sale by collecting the payment; you do it by generating a purchase order, or PO. JotForm’s Form Builder includes a dedicated purchase order payment tool that simplifies B2B conversions.

After you choose a general payment form type, you have two options: You can either use a premade template to get your form published as quickly as possible, or you can build your own payment form with JotForm’s Form Builder.

Payment form templates

JotForm offers dozens of payment form templates for all sorts of payment scenarios. When you use a template, most of the work is already done for you. Just customize the template to reflect your branding and display your information, and then embed the form directly into your website.

Building a payment form from scratch

You may envision a form that doesn’t quite match any of the available templates. In that case, log into your JotForm account, click the Create Form button, and you’re ready to use the Form Builder.

You can choose from traditional forms, which display all questions on a single page, or the advanced JotForm Cards experience, which offers users a single question at a time. This approach gamifies the payment experience, and can even include friendly micro-animations that reflect your brand and keep customers engaged.

Follow this step-by-step guide, complete with video instructions, to create your first order form from start to finish. There are tips available on how to build the most effective form possible. Once your form is complete, you can even add a customized “thank-you” page to let your customers know the payment is complete.

Your site can’t collect payments without a form of one type or another, and building those forms shouldn’t be an obstacle. Sign up for a free JotForm account to start collecting payments online today.