Custom payment drivers can be added to support any payment provider.
Overview
Lunar provides an easy way for you to add your own payment drivers, by default, there is a basic OfflinePayment driver
that ships with Lunar, additional providers should be added to your Storefront via addons.
Below is a list of available payment drivers.
Available drivers
First party
Made a custom driver that should be listed here? Get in touch on the Lunar discord channel to get it added.
Building your own
A payment driver should take into account 2 fundamentals:
- Capturing a payment (whether straight away, or at a later date)
- Refunding an existing payment
Registering your driver
The payment driver class
The following is the complete class, which is then broken down below.
This is the most basic implementation of a driver, extending the AbstractPayment class provided by Lunar. This class
contains useful helpers that can be used in custom drivers.
See available methods
Releasing payments
This is where you’d check the payment details which have been passed in, create any transactions for the order and
return the response.
If payment is not being taken straight away, any transactions should be set to the type of intent. When the payment is
later captured, it is recommended to create another transaction that is related to the intent via
the parent_transaction_id.
Capturing payments
When you have a transaction that has a type of intent the Staff member who is logged into the hub can then decide to
capture it so the card used gets charged the amount that has been authorised.
You can pass an optional amount, but be cautious as you generally cannot capture an amount that exceeds the original
amount on the intent transaction. If you capture an amount less, services like Stripe will treat that as a partial
refund and no further captures can take place on that order.
Here you should create an additional transaction against the order to show how much has been captured.
Refunding payments
When refunding a transaction, you can only do so to one that’s been captured. If you need to refund an order that hasn’t
been captured you should instead capture an amount less to what’s been authorised.
You should only refund transactions with the type capture.
The AbstractPayment class
Available methods
cart
Sets the $cart property on the payment driver. When using the authorize method, it is recommended to expect a $cart
instance and check for the existence of an order.
order
Sets the $order property on the payment driver.
withData
This method allows you to add any additional data to the payment driver, this can be anything that the payment driver
needs to function, for example.
setConfig
Here you can set up any additional config for this payment driver. By default, this will be called when you register
your payment driver and will take any values which are set in config/lunar/payments.php for that type.
Creating transactions
Depending on how your driver works, you’re likely going to need to create some transactions depending on different
scenarios.
Database Schema
Best Practices
Releasing
When releasing a payment, if you’re not charging the card straight away, you should create a transaction with
type intent. This tells Lunar you intend to charge the card at a later date.
If you are charging the card straight away, set the type to capture.
Capturing
If the card is already being charged, this step can be skipped as payment has already been received.
When capturing a transaction, you should create an additional transaction with the amount that’s been captured. Even if
this is the same amount as the intent transaction.
Refunding