Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

create a way to access the provider original response #6

Open
mbpcoder opened this issue Dec 30, 2024 · 5 comments
Open

create a way to access the provider original response #6

mbpcoder opened this issue Dec 30, 2024 · 5 comments

Comments

@mbpcoder
Copy link
Contributor

Sometimes, we need access to the original response from a provider. To address this, it would be beneficial to implement something like a Response Object.

Instead of returning just a token or a bool value, we could create structured objects (e.g., VerifyResponse) that include:

  • array|null $originalResponse: the raw data from the provider.
  • string|null $originalMessage: the raw message from the provider.
  • string|null $originalResponseCode: the provider's response code as a string.
  • int $responseCode: a standardized response code.
  • isVerificationSuccessful(): a method to check if the verification was successful.

Each provider would then be responsible for creating and returning this type of response object.

However, implementing this would introduce breaking changes to existing integrations. We would need to carefully consider this impact or release it as part of a new version to ensure backward compatibility.

@samuraee
Copy link
Member

I'm not sure about it. In my opinion, it is not necessary to receive an original response from the provider. I have worked with payment gateways for over 20 years and have never encountered this situation. On the other hand, all input and output are logged throughout the entire package methods for debugging and tracking cases.

@mbpcoder
Copy link
Contributor Author

Storing this type of information is seems unnecessary.
However, when developing a general package, it's important to support all or most scenarios.
For example we are storing all relevant information through our payment log.

@samuraee
Copy link
Member

As I said I have logged everything including incoming and outgoing parameters. It's enough for every kind of debugging. by the way feel free to add any required log in any step...

@mbpcoder
Copy link
Contributor Author

mbpcoder commented Jan 1, 2025

I understand that but this isn't meant for debugging purposes but rather to supporting scenarios.
For instance, in our case, we encountered a problematic transaction where the provider required the actual response from us.

@samuraee
Copy link
Member

samuraee commented Jan 1, 2025

As I said some responses are logging via my other (dependency) package laravel-xlog with a lots of useful information. So you can find the corresponding log and give them the actual response.
just add $this->log($response); wherever you need with debug level and I'll merge it for you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants