How an online payment reaches the books

Online payments connect the firm's invoices to two providers: Moyasar for cards and STC Pay, Tamara for instalments. This page explains what happens between the client's click and a matched invoice, so that each screen of the other pages has its place.

The pieces

From the click to the books

1. The offer. The invoice's page on the customer portal, or the link you sent, offers the providers that fit the invoice: not Disabled, published (the firm's own users also see unpublished ones), of the invoice's company, accepting its currency and the client's country, under the Maximum Amount. Tamara also checks its minimum amount, that the currency is the one of the client's country, and, unless told not to, asks Tamara whether the client is eligible.
2. The transaction. When the client pays, a transaction is created and sent to the provider's own form. Its state is Draft, then Pending while the provider works, then Authorized (the money is held), Confirmed (the money is taken), Canceled or Error.
3. The answer. What the client's browser reports is never believed on its own. Moyasar's payment is read back with the secret key, both when the client comes back and when Moyasar's webhook arrives; Tamara's notifications must carry the notification token.
4. The books. Once a transaction is Confirmed, a payment is created in the provider's Payment Journal, posted and matched with the invoice, which shows Paid. Matching the provider's deposit with the bank statement is explained in Banks, cash and currencies.

This last step runs at once when the client comes back to the site. When it cannot, a scheduled job tries again every ten minutes for four days; see Online payment automations.

Authorize, then capture

With Capture Amount Manually on, the provider only authorizes the payment and the books stay untouched until you decide. Capture Transaction takes all or part of the money and starts step 4; Void Transaction releases it. While a payment is pending or authorized, the portal offers no second payment for that invoice. Capture, void or refund an online payment shows the screens.

Test and live

A provider in Test Mode works with test keys and test cards, and no real money moves; Enabled needs live keys. Moyasar refuses a key that does not match the state, because the key alone decides whether a real card is charged. A test or restored copy of the database is made harmless the same way: enabled providers are disabled, the Moyasar and Tamara keys are wiped and the scheduled jobs are stopped.

Saved cards and automatic charges

When Allow Saving Payment Methods is on, the client may keep a card at Moyasar for later payments. On top of saved cards, the Moyasar menu holds an engine that charges a saved card on a schedule:

• Accounting/Moyasar/Recurring Charges: one line per client and card, with an interval (monthly, yearly or every so many days), an amount and the date of the next charge.
• Accounting/Moyasar/Billing Cycles: one cycle per period charged, with its attempts and their result.
• Accounting/Moyasar/Payment Authorisations: the record of the client's agreement to automatic charges, kept as evidence and never edited; a withdrawal is added to it.
• Accounting/Moyasar/Dunning Policies: how many attempts, how far apart, and which e-mails the client receives.

A recurring charge cannot be enabled without an active payment authorisation, and no screen of this app creates one: it is recorded only when a client accepts automatic charges on a subscription page. For a law firm, these menus are where such charges are followed, not started.

What this app does not do

• Register a payment received by transfer or in cash, or match bank deposits: see Customer invoices and Banks, cash and currencies.
• Ask for a prepayment on a quotation: see Quotations.
• The Saudi e-invoice: see E-invoicing (ZATCA).
• Tamara's promotional widget belongs to the online shop's product pages.

Who may do what