One of the most important factors that can determine the right payment solution for a business model is the customer’s user experience. For Independent Software Vendors (ISVs) and Small-Medium Businesses (SMBs) alike, making the checkout process as convenient as possible is a priority, and that process looks different depending on the industry. Contractors, for example, may need to accept mobile payments while at a job site, while TeleMedicine businesses may only require an ecommerce integration for clients to make online payments. Even businesses that have brick-and-mortar locations, such as automotive dealerships, may opt to add payments to their website so customers can choose from a variety of omnichannel payment methods.

Some aspects of the customer experience are more nuanced, such as keeping customers on the business’s website throughout the ecommerce checkout process, or redirecting them to a different site for payment. Some businesses may want to avoid URL redirects because they add a potential point of failure and may have an impact on branding continuity. Those that want to control the entire user experience and provide a fully embedded payments solution should look for a product that doesn’t require a redirect, such as North's iFrame JavaScript SDK or EPX Hosted Checkout.

However, for other businesses, redirecting away from their site during the payment process assures them that they aren’t responsible for any part of the checkout process — the redirect gives them peace of mind that the risk of handling sensitive financial data is completely offloaded onto the payment processor, as with the EPX Hosted Pay Page. To identify the customer experience factors that are important to a business, it is helpful to map out the ideal process that a customer will follow when checking out from their ecommerce store.

The functionality that payment solutions offer varies widely among products. For instance, business models that are structured around customer subscriptions or memberships will need a product that offers subscription management and recurring payment options. Smaller businesses may only need the ability to make sales and refunds, so using a full-featured API might be unnecessarily complex when a shopping cart plugin would work just as well. The feature set that’s best for a business will depend on its specific processes and needs.

For example, some ecommerce businesses that ship goods from multiple warehouse locations may check inventory after an order is placed to identify the best source for the shipment. Under this model, an Authorization request is often sent when the customer’s order is placed, and a separate Capture request is sent when the items are shipped. This business model would necessitate that the payment integration has the ability to send Authorization and Capture requests separately, as opposed to a combined request, which is often referred to as Sale, or Auth and Capture. However, for other businesses that don’t have those constraints, it may be more efficient to capture sales automatically using a Sale endpoint, rather than sending separate requests.

Another business requirement that often translates to a specific feature set is the ability to capture Level-2 or Level-3 processing data. Level-1 data includes the standard fields that are submitted with all transaction requests, but sending additional data can allow businesses to take advantage of interchange discounts. Each level requires more data than the one prior, and the additional parameters required to capture it are only supported by certain products. Businesses that would like to benefit from these interchange discounts need to choose a payment product that’s designed to accept the required additional fields.

Setting up a PCI-compliant payment environment is a large undertaking — businesses that choose to do so need to be familiar with PCI Data Security Standard (DSS) requirements, create a program for maintaining compliance including regularly scheduled audits, and more. However, for many businesses, there is no need to use a payment product that places the business in full PCI scope — many payment products offload some if not all of that responsibility onto the payment provider.

Understanding whether a business needs to handle sensitive credit card data or whether it only needs access to non-sensitive data is a key factor when choosing an integration. Products that reduce PCI scope often return a tokenized card number in the transaction response, but for some business models, that may not be specific enough. For example, businesses in the fitness service sector that offer rewards programs by tracking a customer’s transactions may need access to the entire card number to verify that the program benefits are associated with the correct card.

Defining a business’s payment use cases can help clarify whether it would be best to use a product that minimizes PCI scope or not. Most of North’s embedded solutions minimize businesses’ responsibility for meeting PCI requirements, such as the iFrame JavaScript SDK, but full-featured APIs such as the Server Post API are also available for those that need greater control over transaction data.

Businesses with higher processing volumes, such as insurance agencies or automotive dealers and repair services, may need to have more control over the user experience. In general, the more clients a business has, the more use cases need to be accommodated. Therefore, larger businesses may need payment solutions that have larger feature sets and more functionality. Conversely, businesses with lower processing volumes may only need to make sales and occasional refunds, which may make low-code or no-code solutions a better fit.

A business’s server setup is another factor that can affect which payment product will be a good fit. Some products’ security measures include the use of firewall restrictions. They might implement firewall rules in such a way that the IP address of every server sending requests to the payment processor must be added to its firewall exceptions, otherwise the request will be ignored. This type of product may be a good fit for businesses that funnel requests through a small number of servers. For those that have a more distributed or dynamic network, products that don’t have this type of whitelisting requirement would likely be a more practical choice.

Understanding how the factors described in this article can impact a business’s payment needs is the first step to choosing the right payment integration. The following high-level overview lists the integration types that might be a good fit based on a variety of business needs.

• Payment API

  • Card-not-present or card-present transactions
  • In PCI scope
  • High level of customization
  • Full-featured
  • Access to most or all transaction data
  • Enables a fully customized payment solution
• Point of Sale payments

  • Card-present transactions
  • Reduced PCI scope
  • Medium level of customization
  • Many features available
  • Access to limited transaction data (since PCI scope is reduced, access to sensitive data is restricted)
  • Conveniently integrates with a Point of Sale system
• Ecommerce checkout

  • Card-not-present transactions
  • Reduced PCI scope
  • Low level of customization
  • Fewest features available
  • Access to limited transaction data (since PCI scope is reduced, access to sensitive data is restricted)
  • Simple and quick to integrate