Implement Orders API resource

[VictorAvelar]

Description Implement the API endpoints related to the chargebacks resource and provide test coverage, as an example you might take a look at #6

Additional context The API reference for refunds can be found here: https://docs.mollie.com/reference/v2/orders-api/get-order

[VictorAvelar]

@dwikur21 are you taking this one?

[dwikur21]

Yes, already working on it.

[dwikur21]

@VictorAvelar I have a question about the create order. Here they expect the Payment object to be passed as one of the parameters (optional). My concern is, not all of the parameter listed is in Payment object:

• consumerAccount is in PaymentDetails
• customerId is in Payment
• customerReference is non existent
• issuer is in UsedGiftCard
• mandateId is in Payment
• sequenceType is in Payment
• voucherNumber is in UsedGiftCard
• voucherPin is non existent
• webhookUrl is in Payment

Should I create a new object for that parameter or edit the existing Payment object?

[VictorAvelar]

As far as I can see in the docs instantiating an order will also create a payment, so I will rather have a custom struct called CreateOrderRequest or something along that line, so that is clear that the information contained is only used for creating an order.

[dwikur21]

Ok, thanks

[dwikur21]

@VictorAvelar what do you think about using this package for checking the required parameters for the request? It will reduce the complexity of parameters checking in my opinion

[VictorAvelar]

@VictorAvelar what do you think about using this package for checking the required parameters for the request? It will reduce the complexity of parameters checking in my opinion

I gave validation a lot of thoughts and here is how I feel we should handle it:

From a package design point of view, I feel we should only provide the transport from the user to the server, if the client wants to have validation then they can have it before calling the endpoint, for strict validation in fact, the source of truth should be the API itself, that way we avoid conflicts, unnecessary complexity and also bringing a new dependency to any user that pulls the package.

Also they can have more control on how their data is processed and we only take care of being the carrier from A <=> B, if B returns a validation error then we will carry back that error to the user.

[dwikur21]

@VictorAvelar what do you think about using this package for checking the required parameters for the request? It will reduce the complexity of parameters checking in my opinion

I gave validation a lot of thoughts and here is how I feel we should handle it:

From a package design point of view, I feel we should only provide the transport from the user to the server, if the client wants to have validation then they can have it before calling the endpoint, for strict validation in fact, the source of truth should be the API itself, that way we avoid conflicts, unnecessary complexity and also bringing a new dependency to any user that pulls the package.

Also they can have more control on how their data is processed and we only take care of being the carrier from A <=> B, if B returns a validation error then we will carry back that error to the user.

Ahhh so we shouldn't check any required parameters, let Mollie itself do the checks. If that is so, I'll refactor the refund code.

[VictorAvelar]

@VictorAvelar what do you think about using this package for checking the required parameters for the request? It will reduce the complexity of parameters checking in my opinion

I gave validation a lot of thoughts and here is how I feel we should handle it: From a package design point of view, I feel we should only provide the transport from the user to the server, if the client wants to have validation then they can have it before calling the endpoint, for strict validation in fact, the source of truth should be the API itself, that way we avoid conflicts, unnecessary complexity and also bringing a new dependency to any user that pulls the package. Also they can have more control on how their data is processed and we only take care of being the carrier from A <=> B, if B returns a validation error then we will carry back that error to the user.

Ahhh so we shouldn't check any required parameters, let Mollie itself do the checks. If that is so, I'll refactor the refund code.

but let's not mix concerns, we can have a refactor ticket for refunds.