Create transaction with subscription

[salmanzameer]

The braintree API Braintree::Subscription.create also creates a transaction, but FakeBraintree does not create a transaction when we create a subscription.

How can I create a transaction when I create a subscription? Thoughts!

[gabebw]

I'm not sure there's a good way to do this with the public API right now. Here is the code where we create transactions - as you can see, it's not exactly wrapped up in a neat one-liner.

I can work on this, although pull requests are also welcome! I think the steps are:

• Extract that code to a class so it IS a one-liner, something like FakeBraintree::Transaction.create(transaction_options)
• Call that one-liner when we create a subscription (in the same file)

What kind of transaction does Braintree create when you create a subscription?

[gregblass]

+1

Took me a while to figure out it wasn't an error on my end. Kept getting an empty array for the subscription transactions.

This leaves a pretty significant hole in my test coverage. I'm creating a record of the transaction when the user signs up for a plan, which has the card type, last 4, and amount of the transaction.

Trying to think if I can store this data beforehand and not rely on the returned result.subscription.transactions.first.amount, etc.

Maybe it is time I try to contribute to an open source project.

[gabebw]

Maybe it is time I try to contribute to an open source project.

Hey, great! I started work on this in the gbw-create-transaction-class branch in this repo, with this result: 9fba718 , but don't have time to revisit it right now.

[gregblass]

I can't help but ask, I've been wondering ever since I started working with Braintree - why DID you guys switch to using stripe?

And do you guys maintain a testing gem for stripe more actively than this one? I'm debating switching if there is a testing library available out of the box that has more support.

[gregblass]

I tried to look at and continue the code in that commit but I just don't quite know whats going on. I'd need like a briefing :(

I was able to get around this by getting the last 4 and card type from the payment method if its being created along with the subscription, or just sending the last 4 and card type back to the server via hidden form parameters and storing the data in instance variables to use when creating the transaction if its an existing card. Then I know the amount based off the plan price.

Once this is implemented I'll refactor my code to store the info from the transaction result instead, but this works for now.

[gabebw]

We do not maintain a Stripe testing library, though other people might.

[gregblass]

Another need for this is to verify that the user's card was charged a certain amount. This is necessary in the case of a plan upgrade. Lets say they upgrade to a more expensive plan in the middle of the month. They are charged a prorated fee by passing an addon to the subscription to set the one time prorated price this month. There is currently no way to test this without the transaction being returned along with the subscription. I can't even just find the transaction after the fact in the test and verify the amount because I don't have the transaction ID, and transaction.search isn't implemented in fake_braintree either. So there is definitely a functionality gap here for anyone trying to build a subscription/plan based app like slack or basecamp does it.

[gregblass]

I am taking a stab at this right now. This is the first time that I am contributing to an open source project so I am treading in uncharted waters. Definitely out of my comfort zone and difficult for me...

[gregblass]

So I've spent two days studying this code and trying to get this gap covered. The biggest thing I'm struggling with right now is that not only does the subscription creation need to create a transaction in the registry and return it with the response (which I pretty much have working), I need to have the subscription get the amount its supposed to charge the transaction for from the plan.

There isn't anything in this library yet at all for the plan.

I'm wondering if I should just roll my own subscription code at this point. Or just not test this part.

[gregblass]

So at this point I'm really in over my head unless someone can help me with a strategy to fake the plans too. I'd be happy to keep working on this if someone wants to give me a rundown there.

The best I can guess at this point would be to add another post endpoint in sinatra_app.rb for plans (how and where are you guys getting those URL's)? And then create a plan.rb in fake braintree like a transaction, then have the subscription find its plan by the plan_id and get its amount, and create the transaction with that amount. Then roll out prorated months using discount amounts.

I'm not sure if I'm missing any other pieces of the puzzle there. Ideally if one of you guys who really understands this library wants to do a quick codementor session or video chat for 15-30 mins and help me on the engineering side of this, I'll continue spending time trying to fill out this functionality.

And on an even greater level, I'm just wondering how important it is to actually keep this fake code as close to what is happening in the real Braintree code as possible. Like, can I look and see how braintree is getting the plan amount when creating the subscription? If its not really the same, whats the point? How did you guys kinda get this started in the first place...by looking at the Braintree code? These are all things that have been going through my mind that I'd love to chat with someone about.

Other than that I've just about reached the end of my abilities on my own.

[wacii]

The urls as well as most of my understanding of braintree came from reading the (braintree gem)[https://github.com/braintree/braintree_ruby]. Anything that the source didn't explain, the tests generally did. For the server related code, at least.

I wouldn't add an endpoint for creating plans as there is not one in the actual service. Instead you are expected to create and manage plans through the dashboard. So just define some method on fake braintree to add plans to the registry( or wherever).

But any logic behind subscriptions you want you are going to have to implement. I don't see the benefit in doing much of this though. Just create plans and spit out a transaction. How braintree handles discounts and whatnot ultimately has nothing to do with your application.

[gregblass]

Right, duh, there is no programatic way to create plans...its done manually, so no endpoint...

[gregblass]

I just started looking through the actual braintree gem code and it helps immensely. Looks to be exactly what I need to keep going.