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

Helcim API Deprecated ( gateway.helcim.com/api -> secure.myhelcim.com/api ) #18

Open
twcarefoot opened this issue Oct 20, 2017 · 1 comment

Comments

@twcarefoot
Copy link

It appears that this implementation of the helcim API has been deprecated.

https://www.helcim.com/support/article/4-helcim-gateway-api-helcim-api-getting-started/
This documentation is for the legacy Helcim Gateway. New merchants should refer to the Helcim Commerce API documentation.

I am currently implementing the Helcim Direct API into our application and realized our newly generated API user uses https://secure.myhelcim.com/api/ and not https://gateway.helcim.com/api/.

Can anyone offer any advice on how to solve this issue? I am thinking I will fork yours (and update some variables) since I don't have time to write a new gateway package from scratch.

I realize this package hasn't been updated for a long time. I just want to start a discussion about this topic for anyone else coming across the same issue.

Thanks

@judgej
Copy link
Member

judgej commented Oct 22, 2017

I haven't needed to use this package for a while, so have not kept up with changes to the gateway. If you fork and there are any changes needed, just send a Pull Request and I'll get it merged, and generate a new release if that helps too. That should help other people using this package.

It could be that the new Helcim Commerce API is so different that simple changes won't be enough, because they share little functionality. But if this driver can be expanded while retaining the legacy support to help people switch over, even better.

Looking at the documentation, it all looks very familiar. Many gateways these days are switching to REST APIs, and to do so, they are using a white-labelled gateway API server to implement it (if gives them ready-made solutions such as card scanners and multiple payment method support, integrations to accounting platforms etc). That means the functionality for this may already largely be written for another gateway. I can't put my finger on who is the supplier of the API though, but I'll post back if I find them.

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