This document discusses building an API-first service for payments subscriptions. It notes that consumer behavior favors usage over ownership. It recommends designing a flexible API framework to promote ease of use and innovation. The document contrasts top-down and bottom-up API design approaches and argues that legacy systems often force bottom-up designs that result in more complex APIs. It also states that open banking APIs may not truly open up banks due to legacy constraints.

1. Payments for Subscription

2. A new world of possibilities
Consumer behavior
Usage prevails
over ownership
2
User experience
Immediate fulfillment
Technology
API

3. Why we built our service as an API?
Vision
Internet of Things / Payments
Peace of mind crypto payments
3
Go to Market
Ease merchant access
Promote / expose features
Develop a community

4. Designing the right API first
API native companies
Anticipate and build a flexible
framework that doesn’t limit innovation
Top > Down
4
Legacy based companies
Expose multiple legacy resources in a
consistent user-friendly interface
Bottom > Up
vs.

5. Our views on Open-banking APIs
5
Banks have no other choice, APIs are their future
Current legacy forces a bottom-up approach, that makes APIs
more complex and subject to compromise
Banking APIs may not necessarily make Banks more open

6. Thank you