GoCardless Blog

Author here! These 10B log lines are from the last 60 days of activity from https://gocardless.com/ systems.

It includes:

- System logs, such as our Kubernetes VM host logs, or our Chef Postgres machines

- Application logs from Kubernetes pods

- HTTP and RPC logs

- Audit logs from Stackdriver (we use GCP for all our infrastructure)

> do you ever do anything with them that requires you to store so much data rather than just a representative subset?

Some of the logs are already sampled, such as VPC flow logs, but the majority aim for 100% capture.

Especially for application logs, which are used for audit and many other purposes, developers expect all of their logs to stick around for 60d.

Why we do this is quite simple: for the amount of value we get from storing this data, in terms of introspection, observability and in some cases differentiated product capabilities like fraud detection, the cost of running this cluster is quite a bargain.

I suspect we'll soon cross a threshold where keeping everything will cost us more than it's worth, but I'm confident we can significantly reduce our costs with a simple tagging system, where developers mark logs as requiring shorter retention windows.

Hopefully that gives you a good answer! In case you're interested, my previous post mentioned how keeping our HTTP logs around in a queryable form was really useful for helping make a product decision:

https://blog.lawrencejones.dev/connected-data/

Not all banks do SEPA Instant, yeah. I suppose the answer to that is connecting using PSD2 and sending the payment request then checking payment actually went out (using something like https://gocardless.com/). Many countries also have local bank link systems (e.g. in the Baltics it’s common to have dedicated buttons in the payment form for the big 3 or 4 banks everyone uses).

I’m talking about in-person payments though. It would be so easy to implement QR payments backed by the existing SEPA Instant rails. Many bank apps already understand EPC QR codes (usually found on invoices), so shops could just show these to accept payment. In case your bank doesn’t support SEPA Instant, you could show the cashier the receipt in your bank app, which, well, horribly insecure, but probably fine for low-stakes cases like grocery shopping (you don’t want to be banned from your grocery store chain for forging a 35 € payment).

As with everything, if you're going to do SPA, you should do it well. So far, one of the best SPA website I've seen is https://gocardless.com (disclaimer: I work there).

Once loaded it's probably one of the fastest website I've browsed, and it doesn't have any of the drawbacks you mentioned:

navigating to a new page is quick: ✓

navigating back is quick: ✓

remembering scroll position: ✓

cancelling navigation: ✗ but we won't allow duplicate requests so not an issue

SEO: ✓

Navigation and data loss: ? (no idea how we handle that tbh)

Navigation and loading CSS & JS: ✓ we load everything on the first load (~ 880kB) and that's it. I don't think it will ever be worst than MPA

Analytics: ✓

Automated functional testing: ✓ our unit + e2e test suites run in about 4 minutes (CI)

Our splash pages are open-sourced if you want to have a look at our setup: https://github.com/gocardless/splash-pages

At GoCardless, our current support staff (including myself) are pretty technical. We regularly push code to the main project repo, and it's a great way to get the things we want done, done.

For our support documentation, we're using the Desk.com knowledge base. Although not ideal, it works pretty well for us and is at the very least easy to update.

We took steps like this with our blog (https://gocardless.com/blog) which we've now built using Jekyll. This is awesome because:

a) Anyone can write articles if they can write Markdown

b) Full text previews in our GitHub pull requests...with images (perfect for reviewing!)

We want to transfer these great advantages to our help documents. Jekyll really is a great tool for any (relatively) static site, not just for blogs.

(I work at GoCardless).

GoCardless and Stripe tend to solve very different problems. We're a Direct Debit provider, whereas Stripe do card payments.

In short, Direct Debit is great for recurring payments and variable billing. It's traditionally really hard to get access to in the UK if you're a smaller business; but we allow people to sign up instantly and start using it without having to go to the bank.

DD is a great solution if you're in a service business or are charging a similar set of people each month. It's a less good solution if you're doing e-commerce/physical goods, since you need fast payment timings/clearing. That's the sort of problem cards (and therefore Stripe) are optimized for.

More info here: https://gocardless.com/direct-debit/use-cases/

It appears so from this example, where there is a usage based fee

https://gocardless.com/docs/api_guide#pre-authorization

I can't see any guidelines about how you are recommended to approach these types of situation. In some ways pre-setting a max limit is nice for the customer if you warn them when they approach. I know people who have been billed huge amounts on AWS without really realizing. SO long as you hand hold the customer and your pricing model is simple to understand you should be able to make it work out I would think. For upgrades there is probably no reason not to get explicit agreement (presuming it is just a checkbox really, no need to give the acount details again after all), it is variable usage that is more complex I would think.