createCharge fails on Bitcoin payments from Checkout.js

[thoughtpolice]

If Checkout.js is used to generate a TokenId which was created using the Bitcoin option (see here), then createCharge will fail.

The Stripe API endpoint does not respond with a card field inside the Charge object when the charge is made with Bitcoin. As a result, the Charge FromJSON instance fails to parse the object. This results in a charge that looks like it fails due to some API error in the library, but has actually succeeded just fine and looks perfectly OK in the Stripe logs.

This is in some sense related to #19. I would really like to see these issues fixed, because I'd like to use this library on the new Haskell.org donation site without having to use a fork. :(

I've fixed both of these issues in my own private fork. Here's the full patch:

diff --git a/stripe-core/src/Web/Stripe/Types.hs b/stripe-core/src/Web/Stripe/Types.hs
index 68f273a..ec09949 100644
--- a/stripe-core/src/Web/Stripe/Types.hs
+++ b/stripe-core/src/Web/Stripe/Types.hs
@@ -131,7 +131,7 @@ data Charge = Charge {
     , chargeAmount               :: Int
     , chargeCurrency             :: Currency
     , chargeRefunded             :: Bool
-    , chargeCreditCard           :: Card
+    , chargeCreditCard           :: Maybe Card
     , chargeCaptured             :: Bool
     , chargeRefunds              :: StripeList Refund
     , chargeBalanceTransaction   :: Maybe (Expandable TransactionId)
@@ -160,7 +160,7 @@ instance FromJSON Charge where
                <*> o .: "amount"
                <*> o .: "currency"
                <*> o .: "refunded"
-               <*> o .: "card"
+               <*> o .:? "card"
                <*> o .: "captured"
                <*> o .: "refunds"
                <*> o .:? "balance_transaction"
@@ -394,7 +394,7 @@ data Card = Card {
     , cardExpMonth          :: ExpMonth
     , cardExpYear           :: ExpYear
     , cardFingerprint       :: Text
-    , cardCountry           :: Text
+    , cardCountry           :: Maybe Text
     , cardName              :: Maybe Name
     , cardAddressLine1      :: Maybe AddressLine1
     , cardAddressLine2      :: Maybe AddressLine2
@@ -444,7 +444,7 @@ instance FromJSON Card where
              <*> (ExpMonth <$> o .: "exp_month")
              <*> (ExpYear <$> o .: "exp_year")
              <*> o .: "fingerprint"
-             <*> o .: "country"
+             <*> o .:? "country"
              <*> o .:? "name"
              <*> (fmap AddressLine1 <$> o .:? "address_line1")
              <*> (fmap AddressLine2 <$> o .:? "address_line2")

[thoughtpolice]

And to be clear, I don't necessarily propose the above patch as an actual fix. A real fix would be a bit more involved.

If the cardCountry fix and this card bug could be fixed and would be accepted upstream - even with an API break - would you be open to a PR?

[dmjio]

@thoughtpolice,

Thanks for bringing this issue to light. While it is shocking that a Card would not exist on a Charge object, I assume this is residue from Stripe adding Bitcoin much later in their API design process. Stripe probably made the Card field null since it wouldn't make sense in this context. I assume these changes weren't present in the change log either, and Stripe's documentation doesn't seem to be under version control (if it is, we can't see previous versions of it -- unless we use WayBack Machine 😃). It seems like Maybe Card would make the most sense. If you submitted a patch (along with cardCountry turning into a Maybe -- closing #19), you'd kill two birds with one stone. I'd then do the following:

• Major bump to 2.2.0 (closing A release soon please? #48)
• Bump http-streams (closing GHC 8 Support #43)
• Remove embarrassing partial record on (closing Dubious Customer type #40)

cc: @stepcut

[thoughtpolice]

Oh, and actually I'm not 100% sure if that patch alone fixes it... It seems like it does, and I can receive donations when I look in the dashboard (I see the charge) -- but then Stripe sends an email shortly afterwords saying something went wrong, and they're offering a refund with a URL to follow (even though I'm in test mode already?!) I have no clue why just yet, but I haven't tried it out of test mode, either. From memory I don't think it should happen.

I'll maybe drop by their IRC channel to see if I can figure anything out, and look at my dashboard HTTP logs. I'll follow up with this after.

[dmjio]

Hmm that's strange, unsure why dev mode would have that behavior. Definitely keep me posted. Feel free to PR in the meantime, and when resolved, we can release.

[dmjio]

cc @matthewarkin if you have any insight as to why donations would behave differently would be appreciated :) @thoughtpolice, https://support.stripe.com/questions/does-stripe-offer-a-fee-discount-for-non-profit-organizations wonder if API calls would be altered depending on organization status.

[thoughtpolice]

Actually, I think I figured it out. It was because you have to actually enable live Bitcoin transfers in your account, which requires to agreeing to a few extra TOS about conversions, etc. Maybe? I guess this even applies in test mode.

Since I enabled that I don't think I've gotten any more emails, and my prior ones actually do look OK (the Dashboard says the API responded with 200 to charges with Bitcoin TokenIds, even the ones where emails were sent.) So I think that was it.

[dmjio]

@thoughtpolice, ah, makes sense I guess. I bet we could provide a test for this too. I can append it to your PR

[dmjio]

As long as we can create a token corresponding to a bitcoin transaction, it should be testable.

[thoughtpolice]

Bitcoin charges come in the form of py_something, where normal charges are ch_something. I haven't looked at the API for actually generating a charge based on the bitcoin receiver or anything (I still need to read their docs a bit more...). Here's a log from my server in test mode:

[2016-10-01 20:58:19.535416 UTC] OK: Submitted a donation of $3.00 USD (with a charge ID of "py_9IVZptQDyMXv2h"); receipt sent to "[email protected]"

[dmjio]

Well that looks promising to me :) but yes, additional info would help. Might also want to let stripe know about the 501(c)3 status, it seems there is a small fee on bitcoin transactions. Re:Bitcoin, docs also talk about a source object, seems to be newer functionality unsupported in our current API.

https://stripe.com/docs/api#sources

[dmjio]

This lib is due for an upgrade anyways, DuplicateRecordFields + servant-client + aeson generics would really simplify things. Just hard since there is no machine readable spec, must always play catch up.

[3noch]

Any news on this? @dmjio @thoughtpolice

[dmjio]

@thoughtpolice, hai :)

This is in some sense related to #19. I would really like to see these issues fixed, because I'd like to use this library on the new Haskell.org donation site without having to use a fork. :(

Is haskell.org still using your fork of this lib?

[thoughtpolice]

Yes, but I haven't deployed it yet because busy. The patch is still the same, and the source is here: https://github.com/thoughtpolice/haskell-donate/

[dmjio]

#64

[dmjio]

In HEAD, so closing.