Overview
Lunar provides an easy way for you to add your own payment drivers, by default, there is a basicOfflinePayment 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
Community
Made your own driver you want listing here? Get in touch on our discord channel and we’ll 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
First, we’ll show you the complete class and then break it down to see what’s going on.AbstractPayment. This is a class
which is provided by Lunar and contains some useful helpers you can utilise in your own driver.
See available methods
Releasing payments
intent. When you then later
capture the payment, we would recommend creating another transaction that is related to that via
the parent_transaction_id.
Capturing payments
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
capture.
The AbstractPayment class
Available methods
cart
$cart property on the payment driver. When using the release method we recommend expecting a $cart
instance and checking for the existence of an order.
order
$order property on the payment driver.
withData
setConfig
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
| Field | Description | Example | 
|---|---|---|
| id | ||
| parent_transaction_id | The ID of the related transaction, nullable | |
| order_id | The ID of the order this transaction relates to | |
| success | Whether or not the transaction was successful | 1 | 
| type | Whether intent,capture or refund | intent | 
| driver | The driver used i.e. stripe | stripe | 
| amount | The amount for the transaction in cents | 10000 | 
| reference | The reference for the driver to use | STRIPE_123456 | 
| status | Usually populated from the payment provider | success | 
| notes | Any additional notes for the transaction | |
| card_type | The card type | visa | 
| last_four | The last four digits of the card used | 1234 | 
| captured_at | The DateTime the transaction was captured | |
| meta | Any additional meta info for the transaction | {"cvc_check": "pass", "address_line1_check": "pass", "address_postal_code_check": "pass"} | 
| created_at | ||
| updated_at | 
Best Practices
Releasing
When releasing a payment, if you’re not charging the card straight away, you should create a transaction with typeintent. This tells Lunar you intend to charge the card at a later date.
capture.
Capturing
If you’re already charging the card, you can skip this as you already have payment. 🥳
intent transaction.