search

ThePay / api-client

API client for ThePay - payment gate API
4 stars 0 forks source link

added description_for_merchant #10

Closed AlexKratky closed 2 years ago

AlexKratky commented 2 years ago

http://redmine.havelholding.cz/issues/3981

Triplkrypl commented 2 years ago

New response parameter is not realeaset yet, change target branche in to v1.x-stage.

AlexKratky commented 2 years ago

but there is not v1.x-stage, only v1.x-spring and this is for summer release https://github.com/ThePay/api-client/branches/all and I am not sure how to create branch to keep checks (one approval etc.)

Triplkrypl commented 2 years ago

We have checks for all branches started with v, but if we fix break change here, we can release new PHP property without deploying changes on our server. SDK always return null until we kick out new release but merchants developers can implement new interface simultaneously, while we testing new features. This can speed-up integration process.

AlexKratky commented 2 years ago

Break change in SimplePayment is not fixed.

but if we release it with summer release, there will be that key in response, so no need to check if key exists, otherwise I can add key exist check, but then we can merge it to v1.x

Triplkrypl commented 2 years ago

Yes we will always send description_for_merchant key in response, but everyone could create SimplePayment object in their project for some creative reason, we can not prevent of call the constructor outside of our library. So new required input key can break some code, i hope only unit tests where instance can be used as dummy mock. This break changes not affect main interface for developers, but we can not predict how they use our code, i truly recommend check new array key and have new feature without break change as possible.

AlexKratky commented 2 years ago

Yes we will always send description_for_merchant key in response, but everyone could create SimplePayment object in their project for some creative reason, we can not prevent of call the constructor outside of our library. So new required input key can break some code, i hope only unit tests where instance can be used as dummy mock. This break changes not affect main interface for developers, but we can not predict how they use our code, i truly recommend check new array key and have new feature without break change as possible.

Well now I understand, however it is not documented to use it like that. Every change in input/output of any method could be BC, even after adding check if key is set, someone can have a test, that will check count of key of method toArray() for example