After initial installation, we suggest that you run the following pages:
The Stripe Payment Method Code is a payment method that you can add to a customer record (and hence flowing through to Sales Invoices). It provides an additional method for filtering Sales Invoices that you want to be added to a Payment Batch.
On initial installation of Astral Pay, this field is set to ‘enabled’ if SMTP is configured within Business Central, or if there is an Email Account that has been set as ‘Default’.
However, the functionality is currently not used any further within the system.
This field determines the default language that will be used for the PayLink emails. If not set here, it will default to ‘ENG’.
When a PayLink Email is generated, the language template to use will be initially set to the value in this field. Then, if the Customer has a language code set, it will be overridden to the customer specific language code. The process will then select the language template to generate the text for the email.
When set, all emails sent will have a BCC to this email address.
When Stripe ‘transactions’ are posted via a journal, there is the possibility that the journal may have multiple currencies and currency triangulation differences. For this reason, where the resulting journal is slightly more complex than normal, each line will utilise the ‘Balance Account No.’ field in the journal, meaning that each line in the journal is in effect a single line balancing journal.
Using the ‘Balance Account Type’ and ‘Balance Account No.’ fields in a journal is an alternative way of posting a journal but is standard functionality of Business Central.
If the ‘Balance Account No.’ field is used, once the transaction is posted, the total postings made to the ‘Posting Control Account’ will be zero.
The ‘Posting Control Account’ should be an account that allows ‘Direct Posting’, and should not have the General Posting or VAT Posting fields populated.
The ‘Fees Account Type’ field allows you to chose whether the ‘Fees Account’ is a G/L Account or a Vendor. Depending on your location, the Stripe Fees that are deducted may include taxes such as VAT.
We would suggest that the best configuration is to treat the fees deducted from each payment as a part payment towards the monthly fees invoice received from Stripe. You would post the monthly invoice from Stripe in the same manner that you would any other vendor invoice, and take care of the VAT and/or other taxes whilst posting the invoice.
The ‘Fees Account’ will be either related to the General Ledger Accounts or the Vendor, depending on the value selected for the ‘Fees Account Type’.
When a transaction is posted, any fees referred to in the transaction will be posted to the account specified in the ‘Fees Account’.
If the ‘Fees Account Type’ is set to ‘G/L Account’, the G/L Account selected must allow ‘Direct Posting’.
The account specified here must be a ‘G/L Account’ that allows ‘Direct Posting’. The generation of a Triangulation Difference will be quite rare. It may occur where the payment uses three different currencies while posting. The three currencies will be ‘Local Currency Code’ (as specified in the General Ledger Setup), the Payment Currency and the Payout Currency.
If a Triangulation Difference occurs, the ‘transaction’ will fail auto-posting, and the user will need to post the transaction using the ‘Create Journal Only’ method.
At the time of development of the Astral Pay extension, we believe that this will be rarely encountered. If you find that this is a frequent occurrence, please reach out to us and we can discuss removing this restriction.
As part of the Assisted Application Setup process, a Job Queue Entry will be created to automatically collect Notifications. Notifications for your system are sent to the Astral Pay service as webhooks, and they are stored until your system collects them. These webhooks contain very little data; just an instruction that a resource (a customer, a customer payment method, a subscription, a payment or a payout) has been updated. The "Auto Process Notifications" checkbox instructs the system to Process the Notifications as and when they are downloaded. We suggest that you leave this field checked, unless you are testing and want to see how and when the Notifications come in. If this field is unchecked, you will need to click the "Notifications" tile in the Role Centre and click the "Process" or "Process All" action.
Since most users test the functionality out in their Sandbox environment, the Astral Pay service typically has many ‘Get Notification’ api calls from systems that are no longer being used. Therefore, the Astral Pay service may send a "Pause" instruction to effectively switch off calling our service where we know that no notifications will have been received. Don't worry though, if you were to use the Astral Pay functionality again in the system, the "Pause Notifications" switch will be turned off, and the Notifications will flow through as normal.
When ‘Notifications’ are processed, Astral Pay will retrieve information about Payments, Refunds, Subscriptions and Payouts. Behind all of these objects is a ‘Balance Transaction’, and these are also downloaded to the Astral Pay – ‘Transactions’ area. The ‘Auto Post Transaction’ switch is enabled by default. When enabled, Astral Pay will attempt to automatically post the transactions when they are retrieved.
If not enabled, the ‘Balance Transactions’ will be entered in to the ‘transactions’ area of the ‘Astral Pay’ extension, but will need to be manually posted.
When transactions are created, the Journal Template to use is defaulted from this field.
When transactions are created, the Journal Batch to use is defaulted from this field.
The Sandbox field is generally unavailable for use. It is set as part of the initial setup process, and you will only have the option to choose whether Sandbox should be ticked if you are in your Production Environment. Although not advisable, some Business Central users may choose to have a Test Company within their Production Environment. When in Sandbox mode, all api calls to Stripe are sent with a flag of ‘livemode’ = ‘false’, and as such, no money will be received.
A No. Series is required for the following areas:
These No. Series provide the system with "Nos." for the Business Central reference. These "Nos." correspond to Stripe "IDs". Typically within Business Central, a "No." is restricted to 20 characters in length, whereas a Stripe "ID" can be up to 255 characters.
This switch determines whether you want your users to be able to use Mail Order / Telephone Order payments in Business Central.
Unfortunately, there is no method for ‘Astral Pay’ to determine whether Stripe will allow you to use MOTO transactions, and it is a manual process to have the functionality enabled by Stripe.
As such, we felt that ‘Astral Pay’ users should be made aware of this manual step by forcing a manual process within Astral Pay.
if MOTO payments have been enabled, switching this setting on means the Amount to be paid can be amended. It is therefore possible to take part-payments against sales or service quotes, orders, invoices and posted invoices. When taking a MOTO payment from the Customer card, it is possible to amend the amount and take a payment on account of a chosen amount, rather than pay the whole customer balance.
enabling this setting means that the Sell-to Customer’s Post Code will default on to the MOTO payment page when debit or credit card details are entered.
‘Astral Pay’ adds functionality whereby a PayLink can be generated and added to the Sales Invoice document. The document will therefore contain a ‘Pay with Stripe’ link. However, you may not want this to be placed on all documents and so only enable this switch if you want all sales invoice documents to include the ‘Pay with Stripe’ PayLink.
Note however, that the link is only added if the invoice is outstanding.
'Pay with Stripe' will not be included on documents where the Bill-To Customer has a Saved Card that hasn't expired.
You may want the ‘Pay with Stripe’ link to be automatically added, but only for certain ‘Payment Methods’. For example, if you also use our ‘Astral GoCardless’ extension and the customer pays by direct debit then you may not want them to start paying by Credit Card also.
this dataformula is used to create a filter when reprocessing errored Notifications. If a dateformula is specified, Notifications with a status of Error will be reprocessed if their Created Datetime is within the dateformula filter. For example, if a dateformula of -1D is entered, then all errored Notifications with a Created Datetime of yesterday and onwards will be retried. If the field is empty, no errored Notifications will be automatically retried.
Allows an additional filter to be added when retrying Notification Errors. This filter is set against the "Cause" field on the Notification in the Notifications page. For example, if a filter of customer.created is entered, then only errors with a cause of customer.created will be retried, as long as their Created Datetime falls within the filter set in the Retry Errors Since Dateformula field (see above).
The Registered Company is sent to the Astral Pay service when it is initially registered, and exists as a failsafe to ensure that a copy of the Production company to a Sandbox Environment cannot be used to generate real transactions.
This is a unique identifier for your system on the Astral Pay service.
This is Stripe’s reference for your Account. It is provided to Business Central as part of the Assisted Connection Setup process.
In order to receive Payouts, your account at Stripe must be verified. If not verified, each time you run the "Assisted Connection Setup" wizard, the Stripe "Onboarding" web page will be loaded.