> Do you think I should support Perl versions older than v5.10 given that Perl v5.12's 11th birthday was 2 days ago!? If I decide not to support versions prior to v5.10, does the declaration need to go in the module or just in Makefile.PL?

I dont think :) This is up to you. Some ancient systems still run perl versions with mustache and beards. Not being my opinion so much relevant, I assume 5.10 or 5.14 as my own personal backward compatibility limit.

That said I suppose you must put it in both place, but probably Makefile.PL is enough being the first thing run during installation.

My last module has it stated twice:

use 5.010;
use strict;
use warnings;
use ExtUtils::MakeMaker;

WriteMakefile(
    ...
    MIN_PERL_VERSION => '5.010',
    ...
    },
[download]

I suspect the first one directly aborts the installation (as the file does not compile) and the second can/should generate a report. The redundance does not hurts me.

> take the optional parameters reference and email ..

Here also I'd put some check from a banal existence of a @ to the usage of Regexp::Common::Email::Address

> I don't have an instance of IIS to test it on

The code is meant to run on IIS? I have made something with it and is a pain. Every other solution is better also handling HTTP requests by hand with pen and paper :) Eventually Apache can run on windows, some plack servers too. I'm a windows sysadmin: my best wishes.

> CGI..

Well.. sincerely seing CGI example can make people fly in horror. Anyway I think no new projects use CGI nowadays. There are valid alternatives and mainly Mojolicious and Dancer2. Being in your cloths I'd propose a CGI example as the last one or ones.

Queryin parameters is easy and readable with Dancer2

get '/hello/:name?' => sub {
    my $name = route_parameters->get('name') // 'Whoever you are';
    return "Hello there, $name";
};
[download]

> Having said that, I cannot imagine a situation outside of initial testing, where the end user will not want to send the customer to a different page depending on whether they paid successfully or not. So cancel-url and success-url would be explicitly set.

Reasoning a bit I dont like the solution. Your module should only do the operation needed to interact with this Stripe. I'm not a serious web dev but I think you should avoid it. In Dancer2 or Mojolicious you have the default route / and is the same of your SCRIPT_NAME +/- I suspect will be a pain refactor this part after the module is in production: rethink it if needed.

> $attrs{'error'} = ...

In the constructor your code returns only the last one error set. Then I prefere undef $attrs{error} over setting it to an empty string in the rest of the module.

L*