It looks like version 0.07 was released to CPAN in July 2019. But then there was a significant refactoring that allowed per-request headers like -idempotency_key done in August 2019 (commit cf04d18).

Is there anything preventing 0.08 release to CPAN?

@ivanfreeside asked on RT:

It would be nice if Business::Stripe worked with the Perl standard for
credit card processors, Business::OnlinePayment. Right now
Business::Stripe is kind-of like havin a database driver that doesn't
work with DBI.

We are of course aware that tokenization and recurring payments are a
new part of the base B:OP API and are definitely willing to work with
you to extend and standardize that base API for your needs. See the
AuthorizeNet, PayflowPro and CardFortress modules for examples of
modules that provide similar features.

This is of course a wishlist "bug". :)

Ivan Kohler
Business::OnlinePayment maintainer

Stripe can support Idempotent requests, i.e https://stripe.com/docs/api/idempotent_requests

I was looking at maybe adding this, but I'm wondering about best place in the code for it to hang (that's if its wanted). As it needs to turn into a header, the current header code looks for the Stripe objects longer term api credentials and things like that, but I guess someone may want to add idempotency for a charge, but not something else, so feels like it has to be a per call addition.

We could add an add_headers(hashref) method which gets stored in $self->{headers}, adds them in _compose to @headers, then undeffed ? Any other thoughts ?

In the documentation for creating a token with the following example:

 my $token = $stripe->api('post', 'tokens', 
     'card[number]' => '4242424242424242',
     'card[exp_month]' => 12,
     'card[exp_year]' => 2012,
     'card[cvc]' => 123,
     'currency' => 'usd'
 );

The currency parameter throws the following error:

{
  error: 
  {
    type: "invalid_request_error",
    message: "Received unknown parameter: currency",
    param: "currency"
  },
}

Removing the currency parameter works as expected.

Hi, my understanding is that Stripe will be changing and using things like payment intents (e.g https://stripe.com/docs/payments/payment-intents ) to support SCA (Strong Customer Authentication) https://stripe.com/docs/strong-customer-authentication/migration#sca-updates

I'm a little confused as to whether Business::Stripe will continue to work.

Does anyone know if it will continue to work and be unaffected, or whether there will need to be some code changes ?

The _compose method decides the user wants to POST based on the amount of content params being passed in, not on the user specifying they want to POST.

    if ($_[0] and $_[0] eq 'delete') {
        $res = $self->{-ua}->request(
            DELETE $url, @headers
        );
    } elsif (scalar @_ > 1 || (@_ == 1 && ref $_[0] eq 'ARRAY')) {
        $res = $self->{-ua}->request(
            POST $url, @headers, Content => [ @_ == 1 ? @{$_[0]} : @_ ]
        );
    } else {
        $res = $self->{-ua}->request(
            GET $url, @headers
        );
    }

This means the following request is interpreted as a GET request, regardless of specifically saying I want a POST.

    my $id = $stripe->api( 'post', "payment_intents/$payment_intent_id/capture" );

I can trick the logic to POST by passing in an empty arrayref.

    my $id = $stripe->api( 'post', "payment_intents/$payment_intent_id/capture", [] );

but I shouldn't need to, it should do a POST if I told it to do a POST. Stripe's API allows POST without content, so the client should also.

I may have time to create a pull request later to fix this, with the goal of also retaining the fallback behavior of "do what I mean." But this issue is a request to change the behavior.