React Native SDK from CSG Forte
The World Advertising Research Center predicted that by 2025, 72% of all internet users will solely use smartphones to access the web.
The World Advertising Research Center predicted that by 2025, 72% of all internet users will solely use smartphones to access the web.
Here at CSG Forte, we believe that listening alone is not enough to be truly customer obsessed. We have to learn and respond from customer feedback to deliver the best experiences for our customers.
Why should we talk about Web Content Accessibility Guidelines (WCAG)? The present and future of engagement are online and web based. With the growth of the metaverse, ongoing drive towards digital transformation and meteoric rise in online purchases, the ability to deliver a great digital experience has become table stakes.
Trend trackers have pointed out how much more important the web experience has become since the start of the pandemic. But for the more than 1 in 5 people with a disability, these experiences might come with caveats. Worldwide, more than 220 million people have a vision impairment of some sort and over 2 billion have a disability of some kind. What implications does this have for web design? Quite a lot!
The need for a set of web content accessibility guidelines was recognized decades ago. We’ll explore what those standards are, but how have they evolved over time, and when did they first come together?
To find the origins of WCAG we have to go back to before the Y2K crisis. Back to the previous millennium. The year 1999. On May 5th of that year, the HTML-focused WCAG 1.0 helped shaped the standards for web accessibility and digital experience. In 2008, those rules got an update in the form of WCAG 2.0.
Where the original had focused on HTML, the new guidelines (and the 2018 WCAG 2.1) expressed a technology-agnostic approach to accessibility for “web content on desktops, laptops, tablets, and mobile devices.” The goal of WCAG overall has not changed from creating a more accessible web environment, but each update has given additional guidance on this critical topic.
The standards set out in WCAG 2.1 cover four key factors for accessible design along with a series of conformance criteria to evaluate WCAG compliance. In particular, WCAG 2.1 indicates web content should be perceivable, operable, understandable, and robust. What do these mean?
“Information and user interface components must be presentable to users in ways they can perceive.”
If a user cannot see, hear, or otherwise interact with web content, it is not accessible to them. This means, for example, that non-text content should have transcripts, alt-text, or other features meant to enable screen reading. Perceivable design isn’t limited to text accessibility, but WCAG 2.1 has additional guidelines on creating more perceivable content.
Example: Thanks to labels for all text fields in the screens of CSG Forte Checkout, users can understand what information each field is meant to include, allowing them to complete the form.
“User interface components and navigation must be operable.”
If a user cannot interact with the interface or navigation as designed, then the content therein is not accessible to them. One way to address this is to ensure that all interfaces have keyboard-based alternatives to mouse-based operation. Other types of operability blocks exist, but WCAG 2.1 provides several ways to ensure operable accessibility.
Example: Thanks to correct contrast ratios and keyboard controls to the date picker tool in various CSG Forte offerings, users can input the date they want to pay their bill using only the keyboard.
“Information and the operation of user interface must be understandable.”
If a user cannot understand the content or user interface, then it is not accessible to them. The most basic understandability feature is including language options and translation-friendly pages, but clear labeling and acronym explaining features are other techniques to make web content more understandable. Whatever web content you create, you want your readers and users to understand it. Following the WCAG guidelines makes this that much easier.
Example: Because CSG Forte error messages are described in text along with outlining for invalid input fields, users can parse error messages they might not otherwise understand.
“Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies.
Where the other three factors are focused on making web content accessible to the user, the “robust” category of WCAG guidelines is focused on making content available to technologies used by those users. This means ensuring that pages are parse-friendly for text-to-speech and other technologies.
Where WCAG is a set of guidelines to create more accessible content online, there are other considerations for web content as well. The Americans with Disabilities Act (ADA) and Section 508 (508) contain standards for web accessibility. Unlike WCAG, ADA and 508 have legal ramifications.
This regulation is meant to ensure that the federal government provides accessible services over all information technology communications channels. This extends from phone to web and beyond. Where WCAG provides wide reaching guidance on accessibility, 508 has specific requirements for federal offices and services. These include providing accessible computer, phone, and mobile services to employees and citizens.
ADA regulation is meant to prevent discrimination against Americans with disabilities by businesses, non-profits, and governments. While ADA regulations apply across more areas than web content, digital experiences should be made accessible as well. Although ADA has existed for over 30 years, many websites and digital products have no yet achieved ADA compliance.
OTHER READING: Did You Know CSG Forte is ADA Compliant?
With more than 2 billion disabled individuals around the world, creating an accessible experience isn’t just the right thing to do, it also means reaching a wider audience. Beyond compliance, accessible design allows consumers to do more online, including making purchases and using products.
For example, providing a secure way to validate payments inputs for blind customers can ensure that they enter the correct information. This then means that their transactions can processes correctly. Put in terms of WCAG 2.1, this means ensuring the input is perceivable by the user and that the validation option is operable for someone who cannot see.
As the world becomes ever more digital and with the continuing interest in the metaverse and other cross-platform digital content, being able to meet consumers, corporate clients, and users where they are will remain essential to business success. Providing accessible payment options does require a framework and WCAG provides a powerful starting point for better digital payments.
To learn more about how you can create exceptional accessible online payments, check out CSG Forte’s payment solutions.
What is NSF?
NSF stands for “non-sufficient funds.” An NSF check is a returned check. This means the bank has refused to honor the check because there isn’t enough money in the account to cover it. These are often also simply called bad or bounced checks.
What happens when an NSF check is written?
When an NSF check is written, a number of negative consequences may follow. The financial institution of the person writing the check makes one of two choices:
Allowing the check
The bank of the check writer may also decide to let the check push through. This, however, would put the check writer’s account into an overdrawn status. For some banks, this means they will charge the account holder fees simply for overdrawing, but may continue to charge for each day or certain amount that they are over. It can end up burning quite a hole in the wallet.
Refusing the check
For the check writer, the bank may refuse to honor the check. The bank will not allow the funds to process, and the writer will likely be charged a fee just for writing the check.
If the bank chooses not to honor the check, they will return the check to the depositor (the person cashing the check or depositing it into their account as a payment). When this happens, the check will not clear, and the depositor’s bank will also tack on a “Deposit Item Returned” fee (DIR). Potentially, the returned item could sink the depositor’s account into overdrawn status, also initiating an overdraft fee.
Banks consider both the depositors and the check writers as being responsible for the NSF check – and they have no problem making it a very expensive mistake.
How do you protect your business from NSF checks?
NSF checks can be very frustrating and costly to businesses that need to process payments. Some decide not to accept checks at all as a last resort, but this is choice limits the payment options of your customers.
For many businesses, it’s a wise decision to accept paper and eChecks, or electronic checks. This allows customers the flexibility of selecting a payment option that works for them – and many people just want to simply have a payment come right out of their checking account.
But how can business handle NSF checks? It’s wise to have a plan set into place so that when NSF checks appear, it isn’t a complete disaster. NSF re-presentment is your best option, as it allows you to recover the funds for each check.
What is NSF re-presentment?
When an NSF check is written, re-presentment will simply “re-present” the check to the writer’s bank at a later date. This way, the check has another shot to clear. CSG Forte’s NSF re-presentment option lets you select the date you wish to re-present the check, which enables you to choose a time when you think there is a stronger likelihood that the funds are available. You may know, for instance, when your customer gets their paycheck. Scheduling NSF re-presentment on or directly after this date increases your chances of accessing the funds and clearing the check.
Payment platforms are often rigorously designed for a number of factors, including security, speed, reliability, and more – but one of the most integral factors for any payment platform isn’t what you may think – it’s scalability.
What makes a platform scalable is its ability to handle oncoming work that grows and develops. Similar to flexibility, scalability allows users from either end of the platform to transform and change their businesses with the knowledge that the platform will react accordingly, adjusting quickly to maneuver new challenges.
A platform that is not scalable, on the other hand, will suffer. Static platforms fizzle and die, unable to keep up with the growing trends and industry challenges. Look, for example, at the mobile payments industry. The highly scalable applications like Starbucks find themselves responding quickly and adeptly to consumer wants and needs. Mobile pre-ordering, built-in rewards, music applications, and payments are all part of that ever-changing platform – and it doesn’t seem likely that Starbucks will stop anytime soon.
On the other hand, a great number of other mobile applications lay in waste. Unable to accommodate user demands and requests, these platforms failed to drive forward. As a result, they lost users and sales. The platform dies.
Payments platforms, in particular, are specifically sensitive to scalability because of the nature of the payments industry. With ever-expanding challenges and disruptions, platform creators are now required to do more than troubleshoot. They are almost asked to intuit the new big wave, creating solutions before problems occur.
But such is the life for any tech industry, including fin tech.
Payment platforms that cannot scale risk losing users on either side of the platform. Here’s why merchants and other users should consider scalability on their list when shopping for a payment platform.
Plan for business to grow
As a merchant, your aim is for business to grow, not shrink. Your payment platform should be able to adjust with you. As you increase volume, you should be able to easily move into higher processing levels without much issue. Be sure that your processor can accommodate changes in volume and speak to them about potential contract savings, as well. Many processors offer discounts the more you process.
Expect high functionality
The platform should not be disrupted no matter how little or how much you are processing. You should still be able to perform all of the functions you need regardless of your business size. There’s no reason any of the features you’ve been using at one level cannot translate to another.
Lower risk when business changes
Scalable platforms are more than just flexible. Because they can adapt, if you need to make changes because of a hardship or short-term change, a scalable system is going to help you adjust through this time period. In lieu of terminating contracts or being forced to switch processors, which is a lengthy and arduous process, a scalable platform will allow you to tighten the reins momentarily without much cost.
Increased opportunity for newer features
Scalable platforms are usually more likely to receive system updates and changes as trends come, which increases your opportunity to test out newer features as they are making waves. Static platforms are less inclined to update frequently and most likely will not adopt newer technologies. If you’re interested in the new and shiny, a scalable solution gives you a better opportunity, and it’s much easier to test out than transferring everything to an all-new system or processor.
Scalability is one of the most important features for payment platforms, landing high on the list for merchant shoppers. CSG Forte offers a scalable platform that adapts to changing business and takes both cards and eChecks. For more information, visit www.forte.net or call 866.290.5400.
A RESTful web service or API is a type of application program interface that uses HTTP requests and is based on “representational state transfer” (REST) technology. Application program interface, or API, is code that sets the uniform standard for how a developer writes a program that needs to request something between operating systems or applications. Using HTTP requests, REST API can perform operations like GET, POST, PUT and DELETE.
A REST API is preferable to SOAP (Simple Object Access Protocol) API technology for a number of reasons. RESTful APIs are:
In addition, documentation for REST is easier to understand, returns readable results and permits many different data formats. REST is also especially good for cloud-based applications because of its stateless calls, which are beneficial because nothing is kept between REST executions and because stateless calls are easy to redeploy and to scale. These are all good reasons to select REST instead of SOAP, especially when using CSG Forte products and features like our Virtual Terminal, reporting or Forte.js.
CSG Forte’s REST API can be used for a number of scenarios, including transaction management, application submission, Webhooks, tokenization and customized application design. It supports multiple programming languages, such as JSON, Java, PHP, Ruby and VB.NET.
REST is best suited for those merchants who are tech-savvy and have developer resources to consume our API calls, such as ISVs with multiple merchants or third-party app developers that aim to receive and leverage our webhooks.
For code samples, visit our documentation. If you need assistance determining which API is right for you, contact us at 866.290.5400.
Since all of our recent chatter about omni-channel is centered on multiple channels, here’s a quick breakdown on payment channels and what we offer.
A payment channel is basically any way that a customer might make a payment or anywhere that you (as a merchant) might accept a payment. This is slightly different from retail channels, which might include bricks-and-mortar, catalogs, and online shopping/eCommerce sites. Payment channels are generally related to these retail channels, but are more specifically how the payment might be made: physical POS systems, phone/IVR payments, online checkout solutions, and mobile payment options, for example.
So these correlate to retail channels, but leave some room for overlap. For example, at a bricks-and-mortar retail channel, you might process payments on a physical POS system (ie the cash register), as well as on smartphones or tablets within the store. Your catalog might accept payments by phone, but also integrate nicely into the omni-channel concept so that customers could walk into your bricks-and-mortar store to pay at the POS, or they could shop the catalog online and pay via online checkout. There is a relationship between payment channels and retail channels, and since you definitely want to start creating a cohesive experience via omni-channel, it’s important to consider what payment channels you might implement.
CSG Forte offers full payment processing support for the following channels:
We can supply card readers, help build a solution with our Virtual Terminal that turns existing computers into instant workstations, and more.
Comes with your own toll-free number and script-building assistance.
Use the iDynamo and our mobile app to instantly take payments on smartphones and tablets.
Our new Checkout is smart, speedy, and stocked with options.
You can accept both credit cards and electronic checks on any of these channels, and each channel comes with our cloud-based Virtual Terminal for transaction management and our powerful payment gateway services. All of the reports funnel into the Virtual Terminal, so you don’t have to worry about piecing things together on your own.
These payment channels don’t necessarily have to correlate only to retail, as well. Government agencies could implement online payments to accept taxes on the web and build a smart physical POS system for in-office payments. Veterinary clinics, dance studios, and other businesses can all benefit from considering an omni-channel approach.
And what’s easier than setting up all of your channels with one company? Get started with CSG Forte today. Give us a call at 866.290.5400 to see what we can do for you.