Comments (8)
This looks better to me as well. It will best the current error handling system. However there might be some challenges for this method.
Some APIs (e.g Pasargad) don't flatter us with any error codes. We might be able to take advantage of /checkTransactionResults
route and track the transactions if there was a problem with verifying it. And it might lead us to some understanding about the origin of the problem.
In other cases though this error handling method will be quite effective. As you've mentioned, knowing whether or not to display the error to the end user is more important than where it was thrown.
Now that you've mentioned v2, I'll be opening up some issues for it. there are some methods that we can offer on some drivers.
For instance:
- Refunding method. Some banks will allow the developer to refund within a fixed amount of time (e.g it's 2h for Pasargad)
- Checking Transaction Method. This one is a little tricky. Some APIs provide it in the same route as
PaymentVerification
route and others in a specific endpoint
Also the code is like a year old I guess it can use some small refactoring (Thanks to the tests you've written it won't be a pain). I'll open an issue for this after I'm done with RSA-xml
to pem
conversion
from monopay.
I kind of regretted doing the monorepo change... haha. I'll probably revert it.
The whole reason I did the monorepo change was because I thought we might need a separate package for NestJS - but I don't think if we do. We could just have NestJS as a peer depencendy and expose the modules and services from monopay/nestjs
Update: OK we're back on the non-monorepo structure we had before.
from monopay.
You can start working on this issue, that sounds great.
from monopay.
Thanks for the well-thought issue.
Honestly, I think we should change how the errors work for v2.
We could separate them like so:
BadConfigError
: The error was caused because the developer has wrong configs for the driver. e.g. wrong credentials, empty fields that are mandatory, etc.UserError
: The error was caused because the user did something wrong. e.g. didn't complete the transaction, didn't have enough funds, etc. - This error is safe to be shown to the end userPaymentGatewayError
: The error was caused because the IPG did something wrong. e.g. was unavailable at that time
I'm suggesting this because I don't think if the developer cares about if the error was a verification error, payment error or a signing error - this seems like a better way to categorize them. And like you said, we can have the description on the error message.
I might be missing something though - as I haven't worked on this repo for a while now. Please let me know what you think about it!
from monopay.
Now that the project is in the monorepo shape, Should I start getting on this issue?
Also it's easier now with zod to throw config errors. it offers a really clean way to throw custom objects
from monopay.
About the config errors. Should we just expose the Zod errors? What do you think?
Do we really need another wrapper around them?
Cause we had a wrapper around the io-ts
error. (BadConfigException
)
from monopay.
I do agree, we may let zod do its thing
I was assuming we should have validation for fields like Email
or Callbackurl
to make sure user is passing the right input but I think we better avoid it. There's usually some validation for it in the developers code anyway so it's kind of unnecessary lost of performance
from monopay.
Yeah our only concern is validating the configuration.
from monopay.
Related Issues (20)
- `RSA-XML` to `pem` format conversion for Pasargad
- Remove classes and just use objects/factory functions
- First-party support for NestJS HOT 1
- Update the documentation site
- "Rebrand" monopay?
- Start using zod
- Gather logos for all drivers
- Cannot find module `drivers/behpardakht` from `src/drivers.ts` HOT 1
- Move to a monorepo structure HOT 2
- Example language switch links are broken
- Allowing `@ts-ignore` in test files
- Beh Pardakht response error code problem HOT 1
- An unknown git error occurred HOT 1
- Unexpected token HOT 1
- description is required HOT 1
- Zarinpal refrenceId is wrong!! HOT 2
- Issue with docs site deployment HOT 1
- update axios version - Axios Cross-Site Request Forgery Vulnerability
- خطای Next Js HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from monopay.