php-vipps
php-vipps copied to clipboard
Please remove refOrderId
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 refOrderId
int she repo: https://github.com/zaporylie/php-vipps/search?q=reforderid
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.
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
Maybe @tht13, as architect, has some input here?