What’s a Rich Text element?

The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.

   * Writes the current year to all elements that match the selector.
  function setCurrentYear() {
    const YEAR_ELEMENTS_SELECTOR = '[fs-hacks-element="year"]';

    const yearElements = document.querySelectorAll(YEAR_ELEMENTS_SELECTOR);
    const currentYear = new Date().getFullYear().toString();

    yearElements.forEach((yearElement) => {
      yearElement.textContent = currentYear;
  document.addEventListener('DOMContentLoaded', setCurrentYear);

Static and dynamic content editing

A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!

How to customize formatting for each rich text

Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.

Case study

[Case study] - How recurring payments work at Logmatic.io

Dec 12, 2017
5 min read
Jeremy Lejoux

(http://logmatic.io “Logmatic.io”) is a log manager platform. Whatever your tech stack, Logmatic.io helps you centralize and manage your logs and thus to be in a position to take smarter decisions based on those collected data.

Few months ago, Logmatic.io started using Telescope, ProcessOut’s monitoring solution to optimize online payments. In the article, Amir, Logmatic’s CEO, share whith us its payment journey at Logmatic.io since the beginning of the company. He also explains the payment challenges he faced while scaling its business and why he decided to use Telescope by ProcessOut

Interviewing Amirhossein Malekzadeh, CEO @ Logmatic.io.

Can you tell us about your background and how you came to look at payments?

Interestingly, I used to work in payments before becoming an entrepreneur. But that was several years ago, before the rise solutions such as Stripe, Adyen or LemonWay. I was then partner of a small consulting firm working mainly for the French retail banks. In those days, merchants had to beg their banks to connect to their online payment portals. Online sales were not that important and payment market was all about pleasing the gigantic offline retailers.  Innovation in that field in France were cobranded cards, a core competency of the consulting firm I was with.

Payments were an old fashioned environment. Offline world was made of prehistoric card terminals that could not be remotely managed. Just imagine the cost of rolling out a new feature : someone had to visit each store and configure every single terminal. Payments were a commodity in which players were not investing massively. In such environment, you can expect the online version to be tough to implement.

That part has not changed yet for the traditional banks:

I contacted our bank who gently returned my call 9 months later. We were off-course already live. Thank you to the new players!

So how did it go to set up your payment systems?

What were the challenges or learnings you can share?

Logmatic is a SaaS B2B service for developers. Our customers are from all over the world, willing to pay with their credit card or through wire transfer. As a we started scaling we needed to automate our back-office and ease customer experience.  Nothing radically new.

We launched our product and then progressively added features such as card payment, having initiated the business with traditional beautifully hand-crafted invoices.  Step 1 was to automate the invoices when we had more than a few dozen customers.  Step 2 was to make them pay automatically on a monthly basis.

So we sat down with the tech team to see how to do this. Their approach was to leverage existing robust solutions so we spend less time on it.  Which boils down to selecting a player because its API is easy to connect and well made (great marketing!).  We had to match that with my business driven agenda.

Firstly I wanted broad acquisition. The three main card issuers (Visa, American Express and Mastercard) do not suffice.  In some countries, local players have a big part of the market.  In others, people would rather make transfers.  So payment were not only to ensure acceptance of these three types of cards. We needed a global payment solution. Not a Visa / MasterCard / AmericanExpress centric solution.

Secondly, I was concerned by the cost (although usually in the startup world your board and the VCs hardly value your margin if your growth rate is good). And in the SaaS business, whether your costs are 1% or 3% or more, it should not change much. Cash has always been an important concern for me as an entrepreneur. And I can not agree to pay 3% to a processor just because their is a lower cost to implement. Any company that would exceed the $100k of monthly payments could think of the $3k they are paying to their processor.  Maybe a few extra hours to connect to a more cost efficient solution can be justified…

I could not think that I had to pay over 3% fees for something that should not cost as much.

Third I was concerned by fraud and payment refusals. Someone is taking the risk in the transaction, so when the card is debited by your PSP, the transaction might be reversed for more than one reason (whether it is fraud or chargebacks, etc.).   This happens but I would love to make sure it does not happen to often.  Here I just thought that if the processor has experience in the market then this should be improved.

We found the right processor which we thought would cover all points : from the cool API to the acceptance, cost and efficiency concerns.  And we rolled it out.

After you went live, what happened?

Did you leave it there and focused again on the rest of your business?

It worked instantly, but then the first disappointments invited themselves to the party on a business side. On the technical it all went fine.

Firstly, I saw they would cover themselves by keeping part of our cash as guarantee for potential chargebacks.  And every week, as our volumes grew for we migrated customers to card payments, that amount grew. Something was wrong here. A small start-up like us was not there to fund a beautiful unicorn. So I picked up my phone and negotiated that. That went ok.

But then as the first reports came in, I saw we were in fact paying more than 3% in fees. That was a bummer and off course you don’t see it directly : they keep the fees and transfer you the rest and you have an email with an invoice. Does not hurt : you do not pay for it, they take it on the fly.  So I deep dived in the details of each transaction, and build a wonderful pivot table (I admit being a pivot table freak) and took a look at all transactions, sliced them by card type, country, amount… The answer was not evident. Only for a few cards were we paying small fees. I checked out with some of these customers.

The answer was then clear : fees were very high for corporate cards, lower for personal cards.

I gave a call to an old friend in payment world and learned indeed that interchange could be about 1.8-1.9% for corporate cards. Then the PSP adds its margin. A total over 3%? That is way too high, but the price to have an easy to implement solution.  Still, it is frustrating.

Then another issue appeared. We started seeing some of our card customers be in debt, as if their payments were not processed. We would see every once in a while payment errors but not knowing why, they were not treated until customer accounting showed late payments.  We did retry automatically outstanding bills, but still some did not work.

So we checked the reason for the refusals : would it be card expiration, a limit reached, fraud, etc.? Most problems were unknown and sometimes retrying them worked. Sometimes it did not.  There is a mystery here.

Today we deal manually with these: we take a look at them and based on the type of refusal, contact the customer or not.  For instance an expired card leads to an adapted email to the card holder.  A repeated unexplained refusal  (most common case) pushes us to gently ask the customer to contact his bank.

In the end, the problems I had with payments were driven by a lack of transparency.  I pay more than I expect. They don’t tell me why. And I feel entrapped in the first contract I set.

And that is how you decided to implement Telescope for more transparency on your payments?

Right. I came across Telescope as I was complaining about payments with a fellow entrepreneur who mentioned to me I should take a look at what you guys were doing.  The promise looked attractive and then it was fairly easy to set up.

Fairly quickly, I got an analysis of my daily payments. I see the first level of monitoring I need to do with our payments, which is enough for me.  I also get some insights on what seems to be going well or not.

In my case, I also use it to look at the details of specific payments — the interface of our PSP being a bit old fashioned, it is easier for me to look at the data in your interface.

This has become my dedicated in-house payment specialist.

Great, happy to hear that! To conclude, from your point of view, who should use Telescope and when?

I think having Telescope on top of your payment provider is a great idea for any online merchants. Payment is a critical and expensive process and be in a position to monitor its economic and technical performance is key to scale your business. My payment journey shows that there are always things that need to be improved when it comes to payments. As I said, before using Telescope, I gathered and analyzed the payment data on my own to be in a position where I can negotiate fees or improve the process and decrease failed transactions. It was time consuming and not always conclusive. Having Telescope on board changed that.

Recent articles

Arrow Left IconLeft iconRight icon buttonSwiper icon right