gocardless-pro-ruby icon indicating copy to clipboard operation
gocardless-pro-ruby copied to clipboard

PayoutItem amount is a string not an integer

Open airblade opened this issue 6 years ago • 3 comments

I was surprised to find that a PayoutItem instance's amount is a string. I expected it to be an integer, or possibly a float, like a Payment instance's amount or a Payout instance's amount.

There's no difference in the API documentation for the various resources' amounts to indicate that the type can differ.

Is this intentional?

airblade avatar Mar 08 '19 09:03 airblade

We store amounts as decimals, rather than floats (to prevent floating point errors and other rounding issues), but it seems like the reason for this is more to allow for the fact that decimals aren't always represented consistently across different systems (e.g. some require a precision to be specified). The string value allows for having the decimal value represented as we store it without having to specify precision or have any other issues with the representation.

Could you please link to the documentation example where the type is not referred to correctly? We should have consistent types for all our amounts, but if there's anything missing, we'll make sure to get it updated.

Greyschale avatar Mar 12 '19 11:03 Greyschale

Sorry for the slow response!

None of the amount docs mentions the type.

I assumed they were all of the same type but evidently not.

In fact the API docs don't mention any types anywhere. It would be great to have the type included in the docs.

airblade avatar Oct 01 '19 09:10 airblade

Thank you for getting back to us!

I assumed they were all of the same type but evidently not.

Payout items are the exception because we return those amounts in fractional currency to one decimal place. (E.g. if the amount of the payout item is £12.345, we'll serialize it as "1234.5".)

We'll make that clearer in the docs.

In fact the API docs don't mention any types anywhere. It would be great to have the type included in the docs.

Agreed, this would be nice to have. Currently, types can be inferred from the examples but this is suboptimal.

Including types in the API docs is not something we're actively looking into but if this becomes a common request, we will reevaluate.

matthieuprat avatar Oct 29 '19 09:10 matthieuprat