Giter Club home page Giter Club logo

Comments (8)

Keivan-sf avatar Keivan-sf commented on August 23, 2024 1

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.

alitnk avatar alitnk commented on August 23, 2024 1

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.

alitnk avatar alitnk commented on August 23, 2024 1

You can start working on this issue, that sounds great.

from monopay.

alitnk avatar alitnk commented on August 23, 2024

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 user
  • PaymentGatewayError: 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.

Keivan-sf avatar Keivan-sf commented on August 23, 2024

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.

alitnk avatar alitnk commented on August 23, 2024

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.

Keivan-sf avatar Keivan-sf commented on August 23, 2024

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.

alitnk avatar alitnk commented on August 23, 2024

Yeah our only concern is validating the configuration.

from monopay.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.