1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-12-27 16:00:59 +01:00
Commit graph

10 commits

Author SHA1 Message Date
epriestley
7d69d8ae6a Remove support for Balanced payments
Summary: See <https://www.balancedpayments.com/stripe>. Just get rid of support since Phortune is a prototype anyway.

Test Plan: `grep`, poked around Phortune.

Reviewers: btrahan, chad

Reviewed By: chad

Subscribers: aurelijus, epriestley

Differential Revision: https://secure.phabricator.com/D12074
2015-03-13 15:47:37 -07:00
Joshua Spence
558e1ee3b8 Define JavaScript functions before they are used
Summary: This should be a fairly minor change that silences a bunch of JSHint warnings.

Test Plan: `arc lint` showed less warnings.

Reviewers: epriestley, #blessed_reviewers

Reviewed By: epriestley, #blessed_reviewers

Subscribers: Korvin, epriestley

Differential Revision: https://secure.phabricator.com/D11064
2014-12-30 02:53:32 -08:00
Joshua Spence
a0d63322b1 Remove unused JavaScript variables.
Summary: There are a bunch of unused variables in JavaScript files. These were identified with JSHint.

Test Plan: It's pretty hard to test this thoroughly... on inspection, it seems that everything //should// be okay (unless we are doing weird things with the JavaScript).

Reviewers: chad, #blessed_reviewers, epriestley

Reviewed By: #blessed_reviewers, epriestley

Subscribers: epriestley, Korvin

Differential Revision: https://secure.phabricator.com/D9676
2014-06-24 03:27:47 +10:00
epriestley
f30f0b30f8 Allow PhortuneTestProvider to add payment methods
Summary: Provide a bare implementation so that you can add PhortuneTestProvider as a payment method. Ref 2787.

Test Plan: Added "cards" through the test provider.

Reviewers: btrahan, chad

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D5772
2013-04-25 09:50:08 -07:00
epriestley
7a5f622820 General cleanup for adding payment methods in Phortune
Summary:
This has no real behavioral changes (except better error handling), it just factors things out to be a bit cleaner. In particular:

  - Move more shared form behaviors into the common JS form component.
  - Move more error handling into shared pathways.
  - Make the specialized Stripe / Balanced methods do less work.

This needs some more polish for nontrival errors (especially on the Balanced side) but none of the error behavior is worse than it was and a lot of it is much better.

Ref T2787.

Test Plan: Hit all invalid form errors, added valid payment methods with Stripe and Balacned.

Reviewers: btrahan, chad

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D5771
2013-04-25 09:49:32 -07:00
epriestley
6efba56448 Implement Balanced Payments as a PhortunePaymentProvider
Summary:
Allows Balanced payment methods to be added. This works essentially the same way as Stripe, except everything is a little bit different.

Slightly more stuff could be shared, but I feel //mostly// good about this. I'll probably do a bit more cleanup next. Some of the error handling is messy, in particular.

Ref T2787.

Test Plan: Added Balanced and Stripe payment methods.

Reviewers: btrahan, chad

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D5765
2013-04-25 09:48:04 -07:00
epriestley
a8bc87578e Clean up rendering of credit card form
Summary:
General cleanup and separation into generic vs Stripe blocks of code.

  - There was an old CC form view for Stripe stuff that I never cleaned up; clean that up.
  - Move non-Stripe CC form rendering into a base class (Balanced can reuse it).
  - Move non-Stripe CC form JS into a shareable class.
  - Simplify JS a bit (JX.Workflow can add extra parameters to a request, so we don't need hidden inputs).
  - Genericize CSS.
  - Depend on Stripe JS directly, if they're down we're not going to be able to add cards anyway.

Ref T2787.

Test Plan: Hit all Stripe errors and added new cards.

Reviewers: btrahan, chad

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D5758
2013-04-25 09:46:59 -07:00
epriestley
9c43029277 Genericize "Add Payment Method" form
Summary:
Ref T2787. For payment methods that allow you to add a billable method (i.e., a credit card), move all the logic into the provider. In particular:

  - Providers may (Stripe, Balanced) or may not (Paypal, MtGox) allow you to add rebillable payment methods. Providers which don't allow rebillable methods will appear at checkout instead and we'll just invoice you every month if you don't use a rebillable method.
  - Providers which permit creation of rebillable methods handle their own data entry, since this will be per-provider.
  - "Add Payment Method" now prompts you to choose a provider. This is super ugly and barely-usable for the moment. When there's only one choice, we'll auto-select it in the future.

Test Plan: Added new Stripe payment methods; hit all the Stripe errors.

Reviewers: btrahan, chad

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D5756
2013-04-25 09:46:32 -07:00
epriestley
4f3b5f0ea9 Phortune v0.1: add payment methods
Summary:
Hook @btrahan's Stripe form to the rest of Phortune.

  - Users can add payment methods.
  - They are saved to Stripe and associated with PhortunePaymentMethods on our side.
  - Payment methods appear on account overview.

Test Plan:
{F37548}
{F37549}
{F37550}

Reviewers: chad, btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D5438
2013-03-28 09:11:42 -07:00
Bob Trahan
cc586b0afa For discussion -- Stripe integration
Summary:
various stripe stuff, including

- external stripe library
- payment form
- test controller to play with payment form, sample business logic

My main questions / discussion topics are...

- is the stripe PHP library too big? (ie should I write something more simple just for phabricator?)
-- if its cool, what is the best way to include the client? (ie should I make it a submodule rather than the flat copy here?)
- is the JS I wrote (too) ridiculous?
-- particularly unhappy with the error message stuff being in JS *but* it seemed the best choice given the most juicy error messages come from the stripe JS such that the overall code complexity is lowest this way.
- how should the stripe JS be included?
-- flat copy like I did here?
-- some sort of external?
-- can we just load it off stripe servers at request time? (I like that from the "if stripe is down, stripe is down" perspective)
- wasn't sure if the date control was too silly and should just be baked into the form?
-- for some reason I feel like its good to be prepared to walk away from Stripe / switch providers here, though I think this is on the wrong side of pragmatic

Test Plan: - played around with sample client form

Reviewers: epriestley

Reviewed By: epriestley

CC: aran

Differential Revision: https://secure.phabricator.com/D2096
2012-04-04 16:09:29 -07:00