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

Please remove refOrderId #47

Open
cloveras opened this issue Sep 20, 2022 · 3 comments
Open

Please remove refOrderId #47

cloveras opened this issue Sep 20, 2022 · 3 comments

Comments

@cloveras
Copy link
Contributor

The refOrderId is no longer used. If it is sent, the payment will go directly to SALE without the RESERVED state, since the refOrderId indicates that it is a follow-up payment of another orderId.

The refOrderId was removed from the official API documentation a long time ago.

Please see: https://vippsas.github.io/vipps-developer-docs/api/ecom#tag/Vipps-eCom-API/operation/initiatePaymentV3UsingPOST

Here are the occurrences of refOrderIdint she repo: https://github.com/zaporylie/php-vipps/search?q=reforderid

@zaporylie
Copy link
Owner

The refOrderId is no longer used. If it is sent, the payment will go directly to SALE without the RESERVED state, since the refOrderId indicates that it is a follow-up payment of another orderId.

Sounds like the refOrderId is being used despite it not being explicitly listed in API description :) So it's now more of a hidden functionality than the lack of it.

Given you removed it in the middle of v2 API lifecycle you should only be able to deprecate certain properties/endpoints, not remove them (as you did with https://vippsas.github.io/vipps-developer-docs/api/ecom/#tag/Vipps-eCom-API/operation/getOrderStatusUsingGET. Otherwise, it will be a backward incompatible change. In that sense the change in question is backward incompatible change.

That being said, luckily I can remove the support for setting refOrderId in a way that won't destroy code compatibility. But for people relying on the old functionality, it will be a breaking change. The way I should make this change in a way that won't destroy people's applications is to mark the property as deprecated and remove it in the next major release of this library. So the question is - do we want to remove support for this hidden functionality all together or do we want to mark it as deprecated so people have time to transition.

@cloveras
Copy link
Contributor Author

Yes, it's hidden functionality. We are not sure if anyone still relies on it, so we have not disabled it complete.y. But it was removed from the API documentation a long time ago, I think 3+ years, but I'm not sure.

The API Lifecycle was written after the /status endpoint was deprecated, so you're right that we're kind of in the middle. The situation is the same there: Some merchants stille use /status, even after many(!) requests from us to switch to the much better /details.

If you can remove the use of refOrderId completely, that would be the best. It is (as mentioned) no longer documented, and it's not used in any of our official plugins.

If someone needs "direct capture", the FAQ has details on how to enable it, and when it is needed (which is probably never). https://vippsas.github.io/vipps-developer-docs/docs/APIs/ecom-api/vipps-ecom-api-faq#when-should-i-use-direct-capture

@cloveras
Copy link
Contributor Author

Maybe @tht13, as architect, has some input here?

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