In many applications (especially where dependency injection is used), it's preferable to not have libraries that rely on global state.

The Stripe PHP library currently takes the approach that every call is done via a static method. While it's fine to retain this as an option, it would be nice if actual objects could be leveraged.

Working on a client's server today (I develop a self-hosted app that uses the Stripe SDK for payments), Stripe's SDK failed with the error: Unexpected error communicating with Stripe. If this problem persists, let us know at [email protected]. (Network error [errno 35]: Unsupported SSL protocol version)

They contacted Stripe and they were told to run this code, which outputted "TLS 1.2" correctly. So TLS 1.2 is supported properly.

The client was running Stripe 3.20.0 (3.21 only adds the Source stuff so it wouldn't have changed anything), so this is an issue with the latest code. After digging into it a bit, I figured out that the problem lay with these lines. This server has CURL_SSLVERSION_TLSv1_2 defined (PHP 5.6), and OpenSSL is current enough to pass that if, so the code was running $opts[CURLOPT_SSLVERSION] = CURL_SSLVERSION_TLSv1_2;, which for some reason causes the problem, because changing it to CURL_SSLVERSION_TLSv1 makes the problem go away. Somehow, explicitly requiring 1.2 is a problem while just asking for any TLS is fine. Removing all the lines linked to above (i.e. not setting CURLOPT_SSLVERSION at all) also resolves the problem. It's also worth noting that PHP's docs themselves recommend not setting CURLOPT_SSLVERSION at all (http://php.net/manual/en/function.curl-setopt.php "Note: Your best bet is to not set this and let it use the default."). So it could be that the best thing to do is to just remove it.

This is not a Stripe-specific issue because in the TLS-checking gist linked above, if I add the line curl_setopt($c, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1_2);, it makes it fail. So it's just something with curl itself on this particular server configuration. But since Stripe does depend on it working correctly, I thought it might be useful to report this, just in case you want to debug and find a workaround for it to make sure others don't have this problem.

I have FTP access to the server and the client's permission to work on debugging this issue so I'm happy to look at whatever is needed and provide whatever information is required.

If this issue doesn't seem worthwhile to you, that's fine, since it's not something affecting a lot of people. I just wanted to make sure someone was aware of it, just in case.

Hello again

I often find myself using the raw string values in my project. I wanted to avoid this, so I added them as constants to the library. This avoids typos in event type strings and also makes it easy to find the event type one is looking for without having to consult the online docs.

:)

This is a large PR that is kind of hard to review -- sorry!

• Rename \Stripe\Error namespace to \Stripe\Exception
• Rename all exception classes to append an Exception suffix
• Add an ExceptionInterface interface implemented by all our exception classes
• Rename the Base / OAuthBase abstract classes to ApiErrorException / OAuthErrorException
  • We're no longer overriding the constructor, instead the abstract classes provide a static factory method to create instances
• Add new exception classes BadMethodCallException, InvalidArgumentException and UnexpectedValueException that wrap the matching SPL exceptions (the purpose of these wrappers is to add the ExceptionInterface interface, so users can catch any and all exceptions raised within stripe-php by catching \Stripe\Exception\ExceptionInterface)
• Rename Api to UnknownApiErrorException
• Add UnknownOAuthErrorException

All the above changes make the exceptions much more idiomatic and less surprising for PHP developers. Defining an ExceptionInterface implemented by all exceptions in the codebase (including standard SPL exceptions by defining wrapper classes) is standard practice for modern PHP codebases.

Hello,

I couldn't comunicate with Stripe on my hosting but everything works fine on my dev machine. I recieved the following message : "Stripe no longer supports API requests made with TLS 1.0. Please initiate HTTPS connections with TLS 1.2 or later. You can learn more about this at https://stripe.com/blog/upgrading-tls".

So to insure that I use TLSv1.2, I used custom cURL options but I got the same error message.

$curl = new \Stripe\HttpClient\CurlClient(array( CURLOPT_SSL_CIPHER_LIST => 'TLSv1.2', CURLOPT_SSLVERSION => 'CURL_SSLVERSION_TLSv1_2', ));

\Stripe\ApiRequestor::setHttpClient($curl);

So I checked the file and modified the line CurlClient.php and modified the line 163 with $opts[CURLOPT_SSLVERSION] = 'CURL_SSLVERSION_TLSv1_2'; insted of $opts[CURLOPT_SSLVERSION] = CURL_SSLVERSION_TLSv1;

Is it the correct way to resolve my problem ?

Regards, apiaget

The default connect and response timeouts baked into the Stripe API Curl client are way too long (see https://github.com/stripe/stripe-ruby/issues/46 as wlel), exceeding the standard TTL for an ELB, for example, and are not configurable in any way by the user.

This PR, while a bit of a hack (I dislike static client configuration as little as the next dev), allows the user to override the CurlClient's default connect timeout and total timeout values to something more sane. Getters are also provided, in case you want to switch the timeout for a single call, then set it back to where it was later. Defaults are stored as constants for easier inspection.

This code $chargeStripe = \Stripe\Charge::all([ 'limit' => 1, 'customer' => $customerStorageEntity->getStripeToken(), ]);

Return ALL charges without filter.

There seems to be some combinations of systems and libraries that given the option for a range in 1.0 to 1.2 will choose TLS 1.0 or 1.1 and then have their requests fail once they go to the Stripe API. This change opts everyone into TLS 1.2, thus avoiding the problem.

There is a possibility that this could affect the upgrades for users on versions of cURL that are so old that they don't have access to 1.2, but we'll need to help these people upgrade anyway given that the depreaction dates for obsolete version of TLS are in the not-too-distant future. If we get any bugs reported in that category, we can consider reverting or solving this another way.

I'm going to keep this open for a bit longer just to wait on a couple more responses on other issues, but it seems like a not-unreasonable way forward here given that some users are being forced to patch vendored Stripe code right now (see #276).

Fixes #276.

Having an issue where "stripe/stripe-php": "2." works with TLS1.2 but "stripe/stripe-php": "3." does not.

When using stripe 2.* it works, returns TLS 1.2 supported, no action required. When using stripe 3.* it does not work, returns TLS 1.2 is not supported. You will need to upgrade your integration.

We verified that our server supports TLS1.2 properly.
We used composer to install the Stripe library.

{
  "require": {
    "stripe/stripe-php": "2.*"
  }
}

Used the php code below to test that TLS1.2 is working properly.

<?php
// Include stripe-php as you usually do, either with composer as shown,
// or with a direct require, as commented out.
require_once("vendor/autoload.php");
//require_once("StripeLibrary/init.php");

\Stripe\Stripe::setApiKey("sk_test_BQokikJOvBiI2HlWgH4olfQ2");
\Stripe\Stripe::$apiBase = "https://api-tls12.stripe.com";
try {
  \Stripe\Charge::all();
  echo "TLS 1.2 supported, no action required.";
} catch (\Stripe\Error\ApiConnection $e) {
  echo "TLS 1.2 is not supported. You will need to upgrade your integration.";
}
?>

I went through the project with CodeSniffer and fixed some of the easy places where it diverged from the Zend style guide.

Indentation should consist of 4 spaces. Tabs are not allowed.

There is an issue with the indentation being 2 vs 4 spaces but I'm not sure it's worth addressing.

I just started working with this library today and I was quite shocked at how old the code felt until I noticed that the minimum PHP requirement in the composer.json file is PHP 5.2.

In my opinion version 2.x of this library should be a top down rewrite that requires PHP 5.4 as a minimum so that we can make use of some modern practises like namespaces and DI injection. Version 1.x would still be kicking around so those that really are stuck on PHP 5.2 can still use the library.

Would you up for this? I'd rather not see yet another Stripe library appear on Packagist, I'd prefer to use an officially supported SDK and I'd be happy to contribute some time towards helping improve the library.

This PR resolves https://github.com/stripe/stripe-php/issues/1400

By allowing to pass params to the underlying nextPage or previousPage methods we can expand data for the resources that are retrieved.

Example:

$stripe = new \Stripe\StripeClient('stripe-secret');

$invoice = $stripe->invoices->retrieve('in_xxx', [
    'expand' => ['lines.data.tax_amounts.tax_rate'],
]);

foreach ($invoice->lines->autoPagingIterator(['expand' => ['data.tax_amounts.tax_rate']) as $line) {
    foreach ($line->tax_amounts as $tax_amount) {
        $tax_rate = $tax_amount->tax_rate;
        echo $tax_rate->display_name . ' ' . $tax_rate->percentage . '%' . PHP_EOL;
    }
}

Describe the bug

Here is the PR https://github.com/laravel/cashier-stripe/pull/1475

To Reproduce

Attempting to generate a pdf of an invoice with more than ten line items

Expected behavior

All lines on an invoice should be expanded, including the tax_rate for a tax_amount.

Code snippets

No response

OS

Ubuntu / Centos

PHP version

PHP 8.1

Library version

stripe/stripe-php v9.9.0

API version

2022-11-15

Additional context

No response

Mocking magic methods is problematic. Add named methods that customers can override.

$mock = Mockery::mock(\Stripe\StripeClient::class);

$terminalMock = Mockery::mock(\Stripe\Service\Terminal\TerminalServiceFactory::class);

$mock->shouldReceive('getService')
    ->with("terminal")
    ->once()
    ->andReturn($terminalMock);

$terminalMock->shouldReceive('getService')
    ->with("readers")
    ->once()
    ->andReturn($reader);

var_dump($mock->terminal->readers);

Fixes #1350.

This pull request

• [x] runs the phpstan job with PHP 8.1 only

💁‍♂️ I doubt that phpstan/phpstan will find different issues on different versions of PHP.

Instances resolved externally can be passed to the factory. This is useful for the mock services that are created in unit tests.

Example use case (using Laravel's mock method which uses Mockery under the hood);

$client = app(StripeClient::class);

$customerService = $this->mock(CustomerService::class, function ($mock) {
    $mock->shouldReceive('retrieve')->andReturn(Customer::constructFrom('......'));
});

$client->getFactory()->setServiceInstance(CustomerService::class, $customerService);

// returns the mock
$client->customers;

When the autoPagingInterator() is used with deletes, only 1 page can be processed, because the last item of the current collection has been deleted, therefore the pager cannot find it to build the 2nd page.

For example (PHP)

        $products = $stripe->products->all(['limit' => 100]);
        foreach ($products->autoPagingIterator() as $product)
        {
            $product->delete();
        }

The above will crash with No such product: 'prod_LIvx6FPSkqMLyL' because the last item in the collection no longer exists.

This can be a problem in a number of cases, i.e.

• Looping through and deleting duplicated saved payment methods based on fingerprint data.
• Test suites where Stripe test data must be cleared before the test suite starts.
• Synchronizing local products with Stripe products in cron jobs.
• etc