phorge-phorge/externals/stripe-php/lib/Stripe/InvalidRequestError.php

<?php

class Stripe_InvalidRequestError extends Stripe_Error
{
  public function __construct($message, $param, $http_status=null, $http_body=null, $json_body=null)
  {
    parent::__construct($message, $http_status, $http_body, $json_body);
    $this->param = $param;
  }
}
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-05 01:09:29 +02:00			`<?php`

			`class Stripe_InvalidRequestError extends Stripe_Error`
			`{`
			`public function __construct($message, $param, $http_status=null, $http_body=null, $json_body=null)`
			`{`
			`parent::__construct($message, $http_status, $http_body, $json_body);`
			`$this->param = $param;`
			`}`
			`}`