Closed Curstantine closed 1 year ago
Hi @Curstantine. By 'internal data field class' do you mean a dedicated payment object instead of the Map that is currently accepted by the startPayment method?
Yeah, a dedicated class for the making the payment object.
@Curstantine Thanks for the clarification. We acknowledge that having a dedicated payment object is beneficial, and technically possible.
However, this means that our team will have to also maintain platform specific code in Dart. Further, most of the logic in the PayHere Flutter SDK is shared with the PayHere React Native SDK.
In an effort to minimize errors and have a consistent interface between the Flutter, React Native and vanilla JS (and any future) SDKS we hope to retain the raw map parameter (for now at least).
Finally, from a developer's standpoint we hope the Map parameter makes it easy to migrate between different PayHere integrations. For example, if you already have a web integration with the JS SDK your team will have an easier time implementing the PayHere Flutter integration since the API is similar.
We hope we explained the rationale behind the raw parameter, but we'd love to hear your suggestions or comments.
Alright
Instead of taking a raw
Map
to the parameter, how about an internal data field class which can be later parsed into aMap
.