Laravel Cashier provides an expressive, fluent interface to Stripe's subscription billing services.

I having this error at try to use this.

The second argument to Stripe API method calls is an optional per-request apiKey, 
which must be a string, or per-request options, which must be an array. 
(HINT: you can set a global apiKey by "Stripe::setApiKey(<apiKey>)") 
(View: /home/vagrant/Documents/Code/Homestead/facturas/resources/views/dashboard/cuenta/partials/_facturacion.blade.php) 
(View: /home/vagrant/Documents/Code/Homestead/facturas/resources/views/dashboard/cuenta/partials/_facturacion.blade.php)

I'm working on updating my project with Cashier v10.0.0-beta.2 and the new Payment Intents API for a few days now and I'm still having issues with my customers having to provide their card details and 3D secure twice. I can't say if I did something wrong or if this is a Cashier related issue so I'm asking here.

I updated my integration following these instruction.

My new customers have to fill a form with their personal information and select one or many subscription plans. At the end of the form there is a Stripe card element. Before the user submits the form, I use Stripe's handleCardSetup method to verify the payment and then submit the form to my controller which creates the subscription(s).

The form contains a SetupIntent key which is generated by the controller before returning the view.

$setupIntent = (new User)->createSetupIntent();

return view('front.auth.register', ['setupIntent' => $setupIntent]);

This is my jQuery code for handling Stripe API.

$('#register-form').on('submit', function(e) {
    e.preventDefault();

    // Disable submit button
    $(this).find('button[type=submit]').prop('disabled', true);

    var clientSecret = $('#setupintent-secret').val();
    var cardholderName = $('#cardholder-name').val();

    stripe.handleCardSetup(
        clientSecret, cardElement, {
            payment_method_data: {
                billing_details: {
                    name: cardholderName
                }
            }
        }
    ).then(function(result) {
        if (result.error) {
            // Inform the user if there was an error
            $('#card-errors').html(result.error.message).slideDown(200);

            // Re-enable form submission
            $('#register-form').find('input[type=submit]').prop('disabled', false);
        } else {
            // Insert the payment method ID into the form so it gets submitted to the server
            var form = $('#register-form');

            form.append($('<input type="hidden" name="stripePaymentMethod" />').val(result.setupIntent.payment_method));

            // Submit form
            form.get(0).submit();
        }
    });
});

I get the Stripe's 3D secure popin everytime I submit the form, but when I confirm the payment using the Complete authentication button, the SubscriptionBuilder's create() method throws an IncompletePayment exception and I have to provide all the card details again. This seems wrong as I already verified the payment with 3D secure.

Here is the code which is handling the new subscription in my controller:

$subscription = $user->newSubscription($planType, $planId);

try {
    // Create subscription
    $subscription->create($request->input('stripePaymentMethod'), [
        'email' => $user->email
    ]);
} catch (IncompletePayment $e) {
    if ($e instanceof \Laravel\Cashier\Exceptions\PaymentActionRequired) {
        return redirect()->route('confirm_payment', [$e->payment->id, 'redirect' => route('home')]);
    } else {
        dump($e); die;
    }
}

When creating a new user with Stripe it would be convenient to accept a Source object id as parameter of createAsStripeCustomer() method.

https://stripe.com/docs/sources/sepa-debit#making-a-charge-request

@jurihub made a pull-request in its own fork of cashier (jurihub/cashier-multiplan#1) to handle SEPA payments.

Is a there a chance such changes would be merged here ? I'm willing to create a PR here if it helps !

Thanks

This PR adds functionality for Stripe checkout and is a continuation of https://github.com/laravel/cashier-stripe/pull/652. All concerns on the original PR have been resolved since.

Docs: https://github.com/laravel/docs/pull/6465

Usage

Checking out a single priced product:

$checkout = Auth::user()->checkout('price_xxx');

return view('checkout', compact('checkout'));

Checking out a single priced product with a specific quantity:

$checkout = Auth::user()->checkout(['price_xxx' => 5]);

return view('checkout', compact('checkout'));

Checking out multiple priced products and optionally assign quantities to some:

$checkout = Auth::user()->checkout(['price_xxx' => 5, 'price_yyy']);

return view('checkout', compact('checkout'));

Checking out a single priced product and allow promotional codes to be applied:

$checkout = Auth::user()->allowPromotionCodes()->checkout('price_xxx');

return view('checkout', compact('checkout'));

Checking out a new $12 priced product (this will create a new product in the dashboard):

$checkout = Auth::user()->checkoutCharge(1200, 'T-shirt');

return view('checkout', compact('checkout'));

Checking out a new $12 priced product together with a Price ID product:

$checkout = Auth::user()->checkout([
    'price_xxx', 
    [
        'price_data' => [
            'currency' => Auth::user()->preferredCurrency(),
            'product_data' => [
                'name' => 'T-Shirt',
            ],
            'unit_amount' => 1200,
        ],
    ],
]);

return view('checkout', compact('checkout'));

Check out a subscription:

$checkout = Auth::user()->newSubscription('default', 'price_xxx')->checkout();

return view('checkout', compact('checkout'));

Check out a subscription and allow promotional codes to be applied:

$checkout = Auth::user()->newSubscription('default', 'price_xxx')
    ->allowPromotionCodes()
    ->checkout();

return view('checkout', compact('checkout'));

Then place any of these in a view:

{!! $checkout->button() !!}

Button Styling

By default a generated checkout button will have the following styling:

It's however easy to style this. Pass either a custom style or class attribute:

{!! $checkout->button('Buy', ['class' => 'text-white bg-blue-500 p-4']) !!}

Todos

• [x] Subscribing to plans
• [x] Charging products
• [x] Single charges
• [x] Webhooks
• [x] Style button
• [x] Tests
• [x] Write documentation

Closes https://github.com/laravel/cashier-stripe/issues/637

Good day.

I'm working on a project that bills users with Stripe Metered Billing (https://stripe.com/docs/billing/subscriptions/metered-billing)

Are there any plans for implementing this functionality? From what I can tell it would involve allowing new subscription creation with a 0 value and a method for creating UsageRecords (possibly similar to the current tab method?)

Thanks, Nic.

This PR aimes at updating the subscription based billing and single charges with the payment intents API to verify payments using 3D secure, amongst else.

Todo

• [x] incomplete state for subscriptions
• [x] Implement a generic way to verify payment intents
• [x] Update plan swapping
• [x] Recurring charges for subscriptions
• [x] Update single charges
• [x] Update invoicing
• [x] Design payment view
• [x] Tests
• [x] Final run-through/cleanup/comments

Changes

Payment Intents

These changes bring support for the new payment intents api to charges and subscriptions. As there are quite some breaking changes here let's go over the most prominent ones below:

Any payment action will now throw an exception when a payment either fails or when the payment requires a secondary action in order to be completed. This goes for single charges, invoicing customers directly, subscribing to a new plan or swapping plans. Developers can catch these exceptions and decide for themselves how to handle these by either letting Stripe handle everything for them (to be set up in the Stripe dashboard) or use the custom built-in solution which will be added in the next commit.

A new status column is introduced for subscriptions as well. Whenever an attempt is made to subscribe to a plan but a secondary payment action is required, the subscription will be put into a state of "incomplete" while payment confirmation is awaited. As soon as payment has been properly processed, a webhook will update the subscription's status to active.

After these changes, webhooks will be a fundamental part of how Cashier works and they're now required in order to properly handle any payment confirmations and off-session updates to subscriptions & customers.

The charge method now only accepts a payment method instead of a token. Developers will need to update their JS integration to retrieve a payment method id instead of a source token. These changes were done because this is now the recommended way by Stripe to work with payment methods. More info about that can be found here: https://stripe.com/docs/payments/payment-methods#transitioning In an upcoming update all card methods as well as the create method on the subscription builder will be updated as well.

Dedicated Payment Page

These changes add a built-in payment page to Cashier. This offers a custom way for users to provide payment confirmations using, for example, 3D Secure.

Developers can redirect to this page after catching an instance of an IncompletePayment exception. They can also pass a redirect url to which the user will be redirected after they've confirmed their payment.

Screenshots for this page can be found here: https://github.com/laravel/cashier/pull/667#issuecomment-506712447

Payment Confirmation Email

These changes add a built-in way for Cashier to send reminder emails to the customer when payment confirmation is needed for off-session. For example, when a subscription renews.

Note that a limitation of this addition is that emails will be sent out even when they're on-session during a payment that requires an extra action since there's no way to know for Stripe that the payment was done on or off session. But a customer will never be charged twice and will simply see a "Payment Successful" message if they visit the payment page again.

Resources

• https://stripe.com/docs/billing/migration/strong-customer-authentication
• https://stripe.com/docs/billing/subscriptions/payment#handling-action-required
• https://stripe.com/docs/payments/payment-intents

Concerns

Use incomplete status as well for failed payments? ✅

At the moment we immediately cancel a subscription when its initial payment fails. But maybe we should allow the customer a chance to use a different payment method first? At the moment his causes Stripe to be polluted with failed subscriptions and voided invoices. It would be better if the invoice just stayed open until paid.

Update 17/05: the new payment view can handle these now as well. A separate PaymentFailure exception will be thrown to inform the user about the specific failure and let them act accordingly.

How to mark subscriptions as incomplete? ✅

When a subscription is incomplete we need to mark it as incomplete as well in Cashier. I first wanted to just set the ends_at to "now" but that won't work since it'll be marked as cancelled, which isn't really wanted. I think the only solution will be to introduce a new status column on the subscriptions table and handle all the use cases in the Subscription model.

Update 20/05: I've now implemented a new status column as suggested above. It's checked in the active method on a subscription and properly cascades to the subscribed method on the billable entity.

Also catch Stripe card errors when performing single charges? ✅

At the moment card errors are caught when paying a subscription invoice, swapping plans or creating a new subscription. They're wrapped in a PaymentFailure exception which is thrown. But Stripe card errors are still thrown as normal when performing single charges. I already implemented the ActionRequired exception for single charges but I'm not sure if we should also catch Stripe card errors in the same way we do for the other parts of the app.

Update 28/06: decided to leave it as is for now. We can always decide to implement this in a future release. The most important part is that the PaymentActionRequired exception is thrown so developers can redirect customers to the payment page.

This PR will provide support for Tax Rates within Cashier. I'm picking up from the PR #818 by @pierrocknroll which already did a great job. I'm trying to be as thorough as possible with this PR.

Basically this PR allows for a customer to overwrite the taxRates method and return a list with Tax Rate ids. These will then be applied by default to any created subscription. By default an empty array is returned which is the equivalent of the currently returned 0 percent.

Closes #657

Tax Exempt and Reverse Charge

This PR also adds new isNotTaxExempt, isTaxExempt and reverseChargeApplies methods to both the Billable trait and Invoice objects to easily determine if a customer is exempted from taxes or when a reverse charge applies. The state for this still needs to be set manually on the Customer. More details here: https://stripe.com/docs/billing/taxes/tax-rates#tax-exempt-and-reverse-charge

Tax Ids

One note: this PR does not provide support for Tax Ids which is also new in Stripe. Tax Ids are handled at customer level. We could perhaps implement better Tax Id support into Cashier at some point but at the moment I don't see a direct need.

Breaking Changes

• Instead of defining a default tax percentage on the Billable model, an array of Tax Rate ids needs to be returned.
• The syncTaxPercentage on the Subscription model has been renamed to syncTaxRates.
• The InvoiceItem class has been renamed to InvoiceLineItem which better represents what it actually is and is the same naming that Stripe uses. Several methods have also been renamed to better reflect this.

Todo

• [x] Implement tax indication on invoice line items
• [x] Check with Stripe invoices how taxes are displayed when tax exemption applies
• [x] Add tests for the new functionality

Reading Material

Stripe migration guide: https://stripe.com/docs/billing/migration/taxes Tax Rates documentation: https://stripe.com/docs/billing/taxes/tax-rates Tax Rates on invoices: https://stripe.com/docs/billing/invoices/tax-rates

New Invoice PDF

Here's an example of a new Invoice PDF:

This PR adds functionality for Stripe checkout. At the moment it'll initiate a new server side session so we can add the checkout to an existing user. Unfortunately I just discovered that this isn't implemented by Stripe yet: https://stripe.com/docs/payments/checkout/server#span-classstepoptionalspan-using-existing-customers

You may specify an existing Customer object for Checkout to use when making one-time payments (this does not yet work with plans and subscriptions).

We'll have to wait until Stripe implements this before continuing with subscriptions. We can already see at implementing checkout for single charges though.

Todo

• [ ] Subscribing to plans
• [ ] Swapping plans
• [ ] Single charges
• [ ] Webhooks (Payment Fulfillments)
• [ ] Style button
• [ ] Tests
• [ ] Write documentation
• [ ] Prefill session id in success link: https://stripe.com/docs/payments/checkout/fulfillment#webhooks

Concerns

Below I'll try to list all concerns I encounter during development.

Existing customers can't yet be passed along when subscribing to a plan ✅

This is vital for Cashier to work so until this gets implemented on Stripe's end this PR is basically blocked.

https://stripe.com/docs/payments/checkout/migration#client-subscriptions

Update 02/10/20: Stripe has since provided support for this.

Trial days seem to work differently for Checkout sessions ✅

Current api for subscriptions: https://stripe.com/docs/api/subscriptions/create#create_subscription-trial_end

Api when creating Checkout sessions: https://stripe.com/docs/api/checkout/sessions/create#create_checkout_session-subscription_data-trial_end

This basically means that you're always required to give either a 48h period or 1 day period when subscribing through Checkout. This seems unwanted and weird. I'll check this over with Stripe.

Update 30/04: Stripe confirmed that the 48h limitation is in place for the following reason:

Checkout Sessions are active for 24 hours after their creation and within that timeframe, your customer can complete the payment at any time. We require the trial start least 48 hours in the future so that there is still at least a 1 day trial if your customer pays at the end of the 24 hours.

I've implemented this here: https://github.com/laravel/cashier/commit/ff9946d4c88cbefdb483829da3a0f18612e57854

Unclear how to upgrade or downgrade using Checkout ✅

The migration guide covers creating new subscriptions but no mention is made on how to upgrade or downgrade plans. We'll need this before support for plan swapping can be given.

Update 29/04: Stripe has confirmed that this isn't included yet.

Update 02/10/20: Stripe has since released their new customer portal that takes care of swapping plans.

Unclear how one-off invoices work ✅

At the moment it's unclear how the invoice method on the billable entity would work with Checkout (or payment intents). I've asked this question to Stripe on Twitter and awaiting their feedback.

Update 02/10/20: I'm not sure why I brought this up back when I was working on Stripe Checkout support. This isn't needed at all for Checkout.

Although I'm getting the Stripe Token like so:

in Billable.php line 385
at User->updateCard(object(Token)) in SubscriptionBuilder.php line 212
at SubscriptionBuilder->getStripeCustomer('tok_19oWykA5zF9kYK3AAOoQP6YM', array('email' => '[email protected]')) in SubscriptionBuilder.php line 177

I'm getting the above error, the stripe_id is saving within the users table but nothing else. Is cashier up to date with new changes at Stripe?

@taylorotwell @themsaid

• Cashier Version: 10.1.1
• Laravel Version: 5.8.19

Description:

Our application has a "switch plan" feature which we used swap() to charge the user and change their plan. With the new Cashier version, we need to use swapAndInvoice() in order to change the plan and also collect the money. While the documentation suggests that we catch the exception and redirect the user, this doesn't happen with any of Stripe's testing cards and all subscriptions are marked as past_due status.

Steps To Reproduce:

1. Subscribe a user to a Stripe plan with any of the testing cards: 4000002500003155, 4000002760003184, 4000003800000446.
2. Swap the user to a new plan using swapAndInvoice().

All testing cards will fail at https://github.com/laravel/cashier/blob/10.0/src/Billable.php#L234 and return false. The error Stripe returns is Nothing to invoice for subscription which is weird because I see that Stripe is creating an invoice and the payments need confirmation:

This will also leave your subscriptions in the database in a past_due statues:

... which means that the user doesn't have a valid subscription anymore, even that he paid for another plan.

Knowing that the payment is missing a verification, I'd have expected that Cashier would have thrown the exception it suggest on the documentation in order to show the confirmation page. I've dig through the code and haven't found a culprit yet.

That said, I've just tested activating the cashier.payment_notification to sent out a notification when a payment is required. The notification is sent over email, with the correct link to be clicked and confirm the payment. Confirming the payment works, and it gets marked as paid in the Stripe dashboard and sync in the database. I still think we should be redirecting if we know a payment is required, and also we should put a subscription on past_due making it a non-active subscription and loosing access even when the user is actually subscribed to a valid plan.

From what I've tried, it seems like the cancel subscription method isn't working properly. If I call a

$user->subscription()->cancel();

the documentation claims it should cancel the subscription at the end of the period. However, this actually cancels the subscription immediately.

After digging through the code, I found that there was actually another method that can be called that will delay the canceling of the subscription until the end of the period:

$user->subscription()->cancelAtEndOfPeriod();

Running this does correctly delay the cancellation of the subscription to the end of the period in Stripe, but instead of setting a subscription_ends_at value in the Laravel application, it just sets stripe_active to 0 and leaves the ends_at value null.