Connecting Daml Smart Contracts & Ledgers to Payment Systems

It just occurred to me after reading @anthony article on Smart contracts are good, that I have not seen in specific posts or in the documentation about actually connecting Daml-based smart contracts & ledgers, to the financial payments and value transfer/storage systems.

How is it done? As a small business owner (Theoretical), what would I need? Who could service my needs as a solutions provider?

1 Like

Connecting a Daml system to something else is done just like any connection between two systems: you need to write a third system program that talks to both, through their respective APIs.

On the Daml side, we have the JSON API with bindings & codegen for JavaScript, and the gRPC API with bindings & codegen for Java. You can also use any other language that can talk protobuf over gRPC or JSON over HTTP, though you may have to spend a bit more effort copying over your Daml type definitions to that language.

On the other end, well, it really depends on what you’re connecting to. Hopefully your payment system has some form of API, and you need to talk to that.

1 Like

Thank you @Gary_Verhaegen

So I would need to contact any potential payment merchant or my bank of choice, and seek integration details? Excellent.

Does this mean that only a Ledger(s) would need to interface with the global payments system? As all the other parties, either legal persons, entities or systems are interacting with Ledger in the Server/Client model?

1 Like

Hopefully thy already have some form of API documentation, so you don’t need to actually contact them, but yes.

It depends™ (as it often does).

The main hurdle here is that any interaction with a Daml ledger has to respect the Daml privacy model. Daml makes trust explicit, which we believe is, overall, a good thing. However, that can mean you need to plan for things. For example, if you want a single integration that maps all Daml transactions to some external system, you’ll need a single party that is at least an observer of all those transactions. That requires some upfront planning: at the very least, your Daml model needs to account for that extra observer.

If you want maximum privacy, on the other had, you may end up needing to run a separate integration bot per party (and perhaps have each party run their own).

It’s really hard to give more guidance without a more detailed understanding of what you’re trying to do, but I hope this helps a bit.


I just checked my current retail bank and they do have APIs & Documentation but it states “for your organisation that has an account with us”.

I’ll give them a call email them :ballot_box_with_check:

OK, thanks, that all makes sense :+1:t2: :100:

I am not trying to doing any complex or particular as yet but wanted to get the design model, clearer in my mind for planning purposes. It just occurred to me to equate a Daml setup to conventional TCP/IP networks.

An all-in-one Daml model is the equivalent of a Ring or Star topology, while a decentralised Daml model with nodes in different legal entities or systems equates to the current Internet concept or a TCP/UDP P2P system.

Uh oh, too much time on the TCP/IP stack has warped my worldview :grinning:

1 Like