This pull request closes #42.

There are a few things that still need to be done, and on which I would appreciate your input (@sandervanhooft).

Order items "on the tab" collision (?) with Subscription order items.

Currently, because of the nature of the subscription billing implementation, the 'open tab' may collide with subscription billing.

Example 1: calling $user->invoice() may end up invoicing subscription items if they are due for processing (could be the intended functionality?).
Example 2: php artisan cashier:run will invoice the items that we put on the tab, once they are due for processing.

If we intend to split apart subscription billing and one off payments, we can add an extra table tab_items that simply points to the id of an order item that is supposed to be on the tab. After that we can add two scopes onTheTab and forSubscriptions (naming up for discussion of course), and add the forSubscriptions scope to Cashier::run, as well as the onTheTab scope to the invoice method.

My assumption was/is that you would prefer not to split this apart, since it could be nice if a developer can put an extra item on the customers next bill (complementary to the fee for the subscription).

In this case we would need to document this properly, and in my opinion also write some extra tests that do some checking on the aforementioned scenario (subscription + one off payment complimentary usage).

Double checking the payment flow for one off payments

Though this is pretty obvious, you may want to double check if the one off payment flow that is implemented is correct. A quick summary:

Scenario 1:

• Customer has a valid mandate
• One off payment initiated by developer
• Prevent if there are no order items that are due for processing
• We create an invoice + process the payment

Scenario 2:

• Customer doesn't have a valid mandate
• One off payment initiated by developer
• Prevent if there are no order items that are due for processing
• We create a payment at Mollie, and redirect the customer to the checkout
• Mollie calls our webhook.
  • if successful we create an order. (OrderPaymentPaid event)
  • if failed we don't create an order, so the tab stays open. (OrderPaymentFailed event)

This flow is quite the same as the "first payment" flow, except the fact that we are creating a "one off payment", which means we don't create a mandate in the process.

Something you will notice is that the "one off payment flow" is not using/hooking onto the Actions that are currently a feature for subscriptions. This was done on purpose, since I couldn't think of a scenario where you would want to do "anything fancy" with a one off payment. This also means that instead of storing actions in the Mollie Payment metadata, we are simply storing the order items. If someone can think of a valid reason to introduce the extra layer of complexity (the actions), we could revisit this implementation.

Double check the written tests

I'm not completely up to speed with your usual event dispatching for example, in the end I haven't used this package since 1.0 because there were no "one off payment" possibilities, which was my main use case in the application I was building. Kindly check if the tests are up to par, and if they need to be improved/extended.

Notes

• The Laravel\Cashier\SubscriptionBuilder\RedirectToCheckoutResponse class has been reused (for developer friendliness), even though the namespace is now kind of weird; maybe we should flag this as something that can be improved in V2? (since it's a breaking change to move it to a different namespace)

• Instead of using get_class($user) I used $user->getMorphClass(), which supports Laravels MorphMap (I noticed later you used get_class()). You could see this as a breaking change. If a developer has defined a morph map for their User model, it will now use the defined string by the developer instead of the fully qualified name of the User model (though chances are probably very low the generic developer is using this [this is an assumption though :)]). I noticed this later, as well as the assumption we're currently making that the user will always have an id column ($owner->id calls). We should replace this with $owner->getKey() instead in the future, so we support different primary key names. Let me know what your thought are on the above.

To do's

• Add 2 extra variables to the phpunit.xml for usage in ManagesInvoiceTest.php, since one off payments have a different Mollie Payment metadata (they use the order items, not the actions after all.
• (?) Might as well create a simply "entrypoint" for developers, from where they can run 1 test, and copy paste all the necessary Mollie id's to their phpunit.xml. This will (in my opinion) greatly improve onboarding of developers for pull requests (perhaps other pull request?).
• Change ->getMorphClass() calls to get_class.
• (?) Someone will need to add some extra tests for one off payment + subscription complimentary usage.

Let me know your thought on this so far.