npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@paylike/processing-errors

v1.0.0

Published

A list of possible transaction processing errors

Downloads

3

Readme

Processing errors

This package contains a list of the various errors you might see when processing new transactions either through the API or in the frontend.

var errors = require('@paylike/processing-errors');

errors.find(e => e.code === 2);

{
	code: 2,
	text: 'Invalid card details',

	// the user might be to blame?
	client: true,

	// the merchant might be to blame?
	merchant: false,
}

Both client and merchant are true if the error could be the responsibility of either or both.

errors
	.filter(e => e.client)
	.map(e => e.message);

[
	'Invalid card details',
	'Invalid card number',
	'Invalid security code (CSC)',
	'Invalid expire date',
	'Card expired',
	'Insufficient funds',
	'Missing card number',
	'Missing card expiry month',
	'Missing card expiry year',
	'Missing card security code (CSC)',
	'Card amount limit exceeded',
	'Invalid card number or card not supported',
	'Missing amount',
	'Invalid amount',
	'Missing currency',
	'Invalid currency',
	'3-D Secure is required',
	'3-D Secure failed',
	'Declined by cardholder bank',
	'Card restricted',
	'Card rejected',
	'Transaction rejected',
	'Error, please try again or contact us',
];
errors
	.filter(e => e.client && e.merchant)
	.map(e => e.message);

[
	// since the popup does allow `amount` and `currency to be input by the
	// user, it could be a fault of either.

	'Missing amount',
	'Invalid amount',
	'Missing currency',
	'Invalid currency',
	'Transaction rejected',
	'Error, please try again or contact us',
]

Dealing with errors in the frontend

If the merchant field is true you should log the error as fatal and deal with it as a programming error.

If the client field is true, the message should be shown to the user.

Depending on your setup you should decide whether to log and/or display errors that are true for both client and merchant.

Dealing with errors from the server

This is most commonly encountered with recurring payments.

Only a subset of the errors are applicable for recurring payments, typically:

Code | Message | Retry is pointless --- | --- | --- 6 | Card expired | ✓ | 7 | Insufficient funds | | 25 | Card amount limit exceeded | | 8 | Declined by cardholder bank | | 9 | Card restricted | | 10 | Card rejected | ✓ | 11 | Transaction rejected | | 12 | Error, please try again or contact us | |

It is recommended to develop a default strategy for any error, be it network issues or a processing error, for instance by retrying every 24 hours and asking the user to do a manual transaction after 5 attempts. Do not retry more than twice within a 24 hours window.

Such a default strategy will make your system resilient to the addition of new error codes and unexpected failures.

In a later iteration, enhance your code by immediately aborting if the code is either 6 or 10.