Building Payments for an Insurance Startup • Hacker News Board

Re: Building Payments for an Insurance Startup

#31

Post by conductr » Thu, Aug 01, 2019, 3:44 AM UTC

dvlsg wrote: post #24

ThrustVectoring wrote: post #19

Earlier quoted context omitted.

If you store integer amounts of the smallest currency subdivision, you're already ready for foreign currencies. You just need to specify how each currency converts from a representation like `$60` to an integer count like `6000`. This even accounts for non-decimal currencies (which basically aren't in modern use) - just set a conversion factor of 500 or 60 or whatever instead of 100.

Probably worth noting that in some cases the currency alone isn't enough information. For example, gas stations using USD often use more than 2 digits of precision. I suspect (and hope) that situation is reasonably rare, though.

They can’t bill that way though and this is a monetary transfer api

Just like how the complex algorithm of determining insurance rates is likely to yield a long decimal, it has to be rounded to translate to a currency. Heck even things like sales tax being a % requires a rounding calc to be done on majority of transactions before the monetary units are tallied for the “total”

Re: Building Payments for an Insurance Startup

#32

Post by npo9 » Thu, Aug 01, 2019, 4:34 AM UTC

stevekrouse wrote: post #2

Why do you use integers to represent monetary values? It seems like $600 is represented as 60000. Or is that a typo?

By using integers they can avoid a person rounding off fractions of pennies and putting it into their own bank account.

Really, it’s about rounding and floating point math.

Re: Building Payments for an Insurance Startup

#33

Post by devnulloverflow » Thu, Aug 01, 2019, 6:10 AM UTC

phonon wrote: post #15

> Insurance firms sometimes cover extremely “long-tail” risks, such as alien abduction insurance. That's not what "long tail" means in insurance. It does not mean unlikely, it means the claim might need to be paid out years after the period coverage was paid for. (Think current lawsuits about asbestos exposure from the 1970s). https://www.investopedia.com/terms/l/longtail-liability.asp

Well, maybe the aliens will keep returning to earth and at unpredictable intervals demanding money in exchange for keeping the hostage alive.

Re: Building Payments for an Insurance Startup

#34

Post by nradov » Thu, Aug 01, 2019, 11:56 AM UTC

phonon wrote: post #15

> Insurance firms sometimes cover extremely “long-tail” risks, such as alien abduction insurance. That's not what "long tail" means in insurance. It does not mean unlikely, it means the claim might need to be paid out years after the period coverage was paid for. (Think current lawsuits about asbestos exposure from the 1970s). https://www.investopedia.com/terms/l/longtail-liability.asp

The alien abduction insurance was clearly described as a gag gift.

Re: Building Payments for an Insurance Startup

#35

Post by ThrustVectoring » Thu, Aug 01, 2019, 4:54 PM UTC

dvlsg wrote: post #24

ThrustVectoring wrote: post #19

Earlier quoted context omitted.

If you store integer amounts of the smallest currency subdivision, you're already ready for foreign currencies. You just need to specify how each currency converts from a representation like `$60` to an integer count like `6000`. This even accounts for non-decimal currencies (which basically aren't in modern use) - just set a conversion factor of 500 or 60 or whatever instead of 100.

Probably worth noting that in some cases the currency alone isn't enough information. For example, gas stations using USD often use more than 2 digits of precision. I suspect (and hope) that situation is reasonably rare, though.

That's a price, not a balance or amount transferred. Any sub-cent stuff is handled internally by the gas station, then rounded to the nearest cent and transferred to external banking APIs. The gas station is free to use whatever representation it wants for the price and quantity, so long as it rounds to the nearest cent before pushing to the API.

Re: Building Payments for an Insurance Startup

#36

Post by phonon » Thu, Aug 01, 2019, 5:19 PM UTC

nradov wrote: post #34

phonon wrote: post #15

> Insurance firms sometimes cover extremely “long-tail” risks, such as alien abduction insurance. That's not what "long tail" means in insurance. It does not mean unlikely, it means the claim might need to be paid out years after the period coverage was paid for. (Think current lawsuits about asbestos exposure from the 1970s). https://www.investopedia.com/terms/l/longtail-liability.asp

The alien abduction insurance was clearly described as a gag gift.

That's a secondary issue (the writer (CEO?) tried to give an example of a insurance policy that covers a very remote event). So fine, doubly nonsensical.

I would have also done a separate article separating paying premiums to the carrier from the carrier paying out claims. Those are basically two totally different parts of the insurance company, with different systems (usually) and definitely from different bank accounts.

Re: Building Payments for an Insurance Startup

#37

Post by dvlsg » Tue, Aug 06, 2019, 7:57 PM UTC

ThrustVectoring wrote: post #35

dvlsg wrote: post #24

Earlier quoted context omitted.

Probably worth noting that in some cases the currency alone isn't enough information. For example, gas stations using USD often use more than 2 digits of precision. I suspect (and hope) that situation is reasonably rare, though.

That's a price , not a balance or amount transferred. Any sub-cent stuff is handled internally by the gas station, then rounded to the nearest cent and transferred to external banking APIs. The gas station is free to use whatever representation it wants for the price and quantity, so long as it rounds to the nearest cent before pushing to the API.

Sure, I probably should have specified that I meant in general when handling money, not necessarily specifically for handling payment API calls. I've worked on a system that kept track of arbitrary precision separately while using integers to store the values. Worked reasonably well, all things considered.

But you're right, we wouldn't have expected to be able to call something like stripe with that same arbitrary precision. It was all internal pricing.

Re: Building Payments for an Insurance Startup

#38

Post by BillinghamJ » Thu, Aug 08, 2019, 3:22 PM UTC

raphaeljlps wrote: post #28

BillinghamJ wrote: post #27

Stripe Connect makes all of this stuff veeeeery easy. No need to test up trust/FBO bank accounts/etc. for client money - just allocate money to accounts held in the name of the correct parties. Source: built a fairly large insurance company with zero client money accounts by using Stripe Connect Disclosure - we are locked into processing card payments with Stripe only, but have no incentive to say nice things about t…

just to clarify the last part: but have no incentive to say nice things about them. with this you mean you don't get money from them to promote them. Please correct me if I'm wrong.

It means no incentive of any kind - monetary or otherwise