Third Party Payment Providers

Overview

With e-commerce experiencing exponential growth among businesses worldwide, many businesses are now using third party payment providers to take payment for purchases made by their customers. This can mean that the invoices and orders created within shop fronts and websites need to then be imported in to an accounting system such as SBCA (Sage Business Cloud Accounting).

Due to the nature and timing of payouts there are a few elements of the transaction that need to be considered and accounted for.

Considerations

Bank Holding Accounts

Bank holding accounts created for the purpose of handling different 3rd party payment provider transactions cannot prevent the account being incorrectly selected by a user. This differs to the SBCA stripe account that is created as readonly due to SBCA handling all of the ledger postings using its own direct integration with Stripe. This is only true when the Stripe account was created/setup by the user via SBCA. Any stripe account created outside of SBCA or stripe transaction created via a shop front/store outside of SBCA would need to handle the full accounting scenario below.

Businesses Offering Cashback

With the prevalence of contactless payments, businesses may provide customers with a cash back service at the point of sale. For example, a public house may offer cashback to a customer buying drinks.

This scenario would be extremely difficult to reconcile and account for as the payout amount from the 3rd party payment provider, would include the drinks accounted for on the P&L and the cashback amount taken from the cash handling account. It is unknown if EPOS systems split the cashback at point of sale and if the split would be seen in the account activity of the payment or EPOS provider (Square for example).

SBCA Bank Feeds

SBCA provides the ability to connect the bank accounts created in the banking module to bank transaction feeds through open banking. In addition to the bank feed functionality it may also be possible for the business to setup bank rules. Bank rules provide a level of automation that the user defines and when configured may be setup to automatically push payouts from providers seen in the bank feed to the ledgers. If this functionality was implemented, payouts could be duplicated if the integration handling the payment provider payout is also making the postings for the payout.

If bank rules have not been set, it is also possible that transactions appearing in the feed can be manually selected and posted to the ledgers by users.

Accounting for 3rd party payments

Many businesses today have an e-commerce presence wether that be from their own websites or 3rd party shop fronts such as Shopify, WooCommerce and the like. This means sales transactions are generated within those mentioned areas and paid for via third party payment providers offered by the shop front/store. It is only after the creation and payment of the sales transaction that the sales_invoice will be either created programmatically or manually within SBCA.

Unfortunately, there is generally a time delay in the processing of payments between when the customer pays and when the transaction appears in the account of the 3rd party payment provider. This means that the transaction fees and actual payment amounts are often unknown at the point of the sales_invoice being paid.

If a requirement exists to create the invoice and mark the transaction as paid in SBCA at the point of sale, we must consider the fees that will be charged and the eventual payout amount that will appear in the SBCA bank account receiving the payout. Failure to account for this correctly would mean the potential of duplicating payments and the actual payment not being cross referenced with the originating sales transaction.

The following is a simplified example of a £100 no VAT sales transaction originating from a shop front/store being accounted for in SBCA:

Debtors Control Account (Balance Sheet)

Debit (dr)	Credit (cr)
100 (invoice created)
	100 (from bank holding account)

Sales (P&L)

Debit (dr)	Credit (cr)
	100 (invoice created)

Bank Holding Account for payment provider (Balance Sheet)

Debit (dr)	Credit (cr)
100 (allocated to sales transaction)
	100 (clearing amount from suspense account)

Bank Account receiving payout amount from payment provider (Balance Sheet)

Debit (dr)	Credit (cr)
97 (to suspense account, cross referenced to originating sales transaction)

Bank Charges & Fees (P&L)

Debit (dr)	Credit (cr)
3 (payment provider fee to suspense account)

Suspense Account (P&L)

Debit (dr)	Credit (cr)
100 (to bank holding account)
	97 (from Bank Account receiving payout)
	3 (from Bank charges & fees)

Translating the accounting into API Requests

• POST sales_invoice to sales_invoices endpoint with the sales transaction details.
• POST contact_payment for the amount paid by the customer via contact_payments endpoint. Payments and Receipts

After the fees and payout amount is known

• POST bank_receipt for actual Bank Account receiving the actual payout amount to the suspense account nominal.
• POST bank_payment for known transaction fee amount from bank holding account to bank charges & fees nominal.
• POST bank_payment for known payout amount from bank holding account to the suspense account nominal.

Alternatively, the transactions made after the fees and payout amount is known, could be made using the journals endpoint.