DEV Community: Joseph Peculiar

Fintech Needs Sandboxes, Not Just Live APIs

Joseph Peculiar — Sat, 18 Jul 2026 21:51:01 +0000

I’ve been back in the trenches of finance and technology. Fintech, in practice, is rarely one company owning the whole stack. It is a chain of regulated firms packaging compliance-heavy services and reselling them as APIs to the next layer of financial systems. Those systems integrate, wrap, and sell again. A few major players sit near the top, wired into banks, blockchains, or DeFi protocols. Everyone else hangs off those rails.

That model only works if the rails are safe to build against. Lately I’ve been watching a gap that keeps showing up: a lot of fintech APIs are live-only. There is no sandbox. No isolated environment that behaves like production without touching real money, real customers, or real settlement.

This is not unique to fintech. Insurance has the same problem. As a developer you get handed production credentials out of the box. Your staging environment is already broken for that path, because you cannot point the team’s shared config at a live integration and call it “safe.” One wrong request, one shared secret in the wrong place, one webhook firing into the wrong environment, and you are past the point where “we’ll just be careful” is a real control.

That is a bottleneck for building enterprise financial rails.

So teams do what they always do when a vendor leaves a hole. Some invent the missing piece. They stand up mocks. They stub responses. They maintain a fake version of the partner’s API that drifts the moment the real one changes a field, a status, or a webhook shape. The integration looks green in CI and still fails the first time it meets production.

Others do not mock at all. In startup environments, speed is the product. Spending weeks rebuilding someone else’s API in miniature feels like wasted engineering time. So they skip it. They wire staging to live, or they leave that path untested until launch day. That is not recklessness for its own sake. It is a rational response to missing infrastructure.

I try to mock. When a partner has no sandbox, I build a stand-in so the team can keep shipping without pointing every environment at production. It helps. It keeps the rest of the system movable. It is also a bandage.

Mocks are local insurance against a vendor gap. They are not a substitute for a real sandbox. They drift. They under-simulate settlement, compliance edges, and failure modes. They burn time that should have been product time. Every mock you maintain is evidence that the rail you depend on was incomplete.

Sandbox is not a nice-to-have for this industry. It is part of the product. If you sell financial infrastructure, you should ship:

A sandbox that mirrors production behavior, including errors and edge cases
Separate credentials and signing keys from live
A clear mode switch so staging cannot accidentally become production
Webhooks and settlement flows that can be exercised end to end without real funds
Until that is normal, integrators will keep paying the same tax: mock systems for the careful teams, live risk for the fast ones, and delayed confidence in the one path that actually moves money.

Financial rails are only as strong as the environments people are allowed to test them in. Live APIs without sandboxes force builders to choose between speed and safety. That should not be the default. Mocking is what we do in the meantime. It should not be the industry’s answer forever.

How to open/edit/bind ports to running Docker Containers

Joseph Peculiar — Thu, 05 Nov 2020 03:02:04 +0000

You have a running production container (a synced node) and you would want to either edit or bind new ports in this container, as opposed to spinning up a new container.

The following steps should aid you to achieve this.

1.Stop the running Container

docker stop <container-id>

2.Open Docker containers directory

cd /var/lib/docker/containers/

cd <container-id>

3.Edit hostconfig.json

Open hostconfig.json with nano or vim
locate and edit PortBindings with the new ports you want to edit, open or delete.

for instance

"PortBindings":{"18332/tcp":[{"HostIp":"","HostPort":"18332"}],"18334/tcp":[{"HostIp":"","HostPort":"18334"}]}

4.Restart Docker

systemctl restart docker

5.Start container

docker start <container-id>

Binance Chain Dev Series: Part II - Issuing BEP2 Token

Joseph Peculiar — Sun, 05 Apr 2020 16:23:33 +0000

Binance Chain development series
chapter 1:- Setting up a light Binance node
chapter 2:- Issuing a BEP2 token on Binance Chain
chapter 3:- Adding our BEP2 to Binance Dex and Interacting with it using the CLI
chapter 4:- Adding token to trust wallet
chapter 5:- Setting up a full Binance Chain node
chapter 6:- Using the Binance Chain SDK

In the previous chapter, we looked into setting up a light client on the Binance chain blockchain. In this chapter, we will issue a BEP2 token on Binance chain mainnet.

BEP stands for " Binance Chain evolution proposal" and BEP2 tokens are assets on Binance chain which follow the BEP2 standard

Binance Chain at the time of writing does not support smart contracts as seen on the Ethereum blockchain, according to the Binance chain community this was an intentional design decision to improve the performance of the system and eliminate having to support unnecessary features.

for more here's an interesting thread

Let's get our hands dirty

There are 3 steps in this chapter:

1) Create a Wallet

2) Connect our wallet to our node using bnbcli

3) Issue our token

cd into the node-binary folder which we downloaded in the previous chapter

cd cli/{network}/{version}/{OS}
cd cli/prod/0.6.3/linux 
./bnbcli

To create a wallet goto Binance Website or testnet for testnet

or we can generate one using the bnbcli

./bnbcli keys add binance-series

> Enter a passphrase for your key:
> Repeat the passphrase:

The binance-series above is used to specify the alias name of the wallet. you can change this to any name of your preference.

Now we can see our wallet

Keep your Mnemonic and Keystore safe, once compromised you lose all assets in your wallet

To add an already existing wallet use the —recover

./bnbcli keys add binance-series --recover
> Enter a passphrase for your key
> Repeat the passphrase
> Enter your recovery seed phrase

To Issue a token on the Binance Chain we need to make sure our wallet has a minimum of 500BNB which is the fee collected for issuing a token, for more details on this click here

To issue our token "Binance Dev Series" ( BDS) with the supply of 1billion

./bnbcli token issue --token-name "Binance Dev Series" --total-supply 100000000000000000 --symbol BDS --mintable --from binance-series --chain-id Binance-Chain-Tigris --node [https://dataseed5.defibit.io:443](https://dataseed5.defibit.io/) --trust-node

We have issued our token 🎉🎉

—from binance-series:- from our alias wallet named binance-series

—mintable:- The token is mintable ( you can remove this if your token requirement dosen't need it).

Always add an 8 decimal after the supply you intend for your token

ERROR: No account with address was found in the state. Are you sure there has been a transaction involving it

if you're getting that error it means you don't have up-to 1BNB in your wallet

What's Next?

Next chapter we will be Adding our BDS token to the Binance Dex, stay tuned

Binance Chain Dev Series: Part I - How to set up a Binance chain node

Joseph Peculiar — Tue, 31 Mar 2020 23:39:29 +0000

Binance Chain is a blockchain developed by Binance and its community, that focuses on building a performant matching engine and exchange over a decentralized network.

The Binance chain development series is split into 6 chapters and is meant give you a deep dive into building with Binance chain

Binance Chain development series
chapter 1:- Setting up a light Binance node
chapter 2:- Issuing a BEP2 token on Binance Chain
chapter 3:- Adding our BEP2 to Binance Dex and Interacting with it using the CLI
chapter 4:- Adding token to trust wallet
chapter 5:- Setting up a full Binance Chain node
chapter 6:- Using the Binance Chain SDK

Let's get started

In this section, we are going to set up a VPS light client node on mainnet

I am assuming you have already set up your cloud VPS server if you haven't click here, I'll jump right into it

There are two types of Binance Chain client

Light client:- does not sync state or relay transactions
Fullnode: - downloads full blockchain and relays transactions

for more details on these, click here

Let's kick off by downloading the node-binary

    git clone https://github.com/binance-chain/node-binary.git

Cd into the node-binary folder you will see the following

let's explore some of the options here

CLI:- this is where we interact with Binance Chain from our VPS, more on this in later Chapters
Docker:- setup node using docker
Fullnode:- Setting up a fullnode
Lightnode:- Setting up a light node

    cd lightnode/prod/0.6.3/linux

version 0.6.3 is latest at time of writing

Starting our node

./lightd --chain-id "Binance-Chain-Tigris" --node tcp://dataseed1.binance.org:80 > node.log &

We have our light client running !!!

What’s Next?

In the next chapter, we will look at issuing a BEP2 token. Stay tuned!

How to run DynamoDB Offline

Joseph Peculiar — Mon, 23 Mar 2020 21:48:31 +0000

I am assuming you are already familiar with the Serverless Framework so I'll jump right into it

Quick overview

Amazon DynamoDB:- is a fully managed proprietary NoSQL database service that supports key-value and document data structures designed to deliver fast and predictable performance.

The Serverless Framework:- enables developers to deploy backend applications as independent functions that will be deployed to AWS Lambda.

Getting started

let's kick off by configuring AWS if not already configured doing this you will have to download the AWS CLI for Windows, macOS, or Linux

The serverless framework will need us to configure access to AWS - This is accomplished by running

aws configure

Install Serverless globally if you haven't installed it already

npm i -g serverless

Now let's setup up the serverless-offline plugin

npm i -g serverless-offline

Install serverless-dynamodb-local plugin

npm i serverless-dynamodb-local

Update your serverless.yml file - add this to the bottom of your serverless.yml file

plugins:
  - serverless-dynamodb-local
  - serverless-offline

Initialize DynamoDB - this initializes DynamoDB offline in your project folder

sls dynamodb install

Run serverless:-

sls offline start

Be sure DynamoDB is running on port 8000 because serverless-offline will use that port as default

you should see the output below

Dynamodb Local Started, Visit: http://localhost:8089/shell

Keep this console running.

Now let's setup dynamodb-admin: this gives us a good GUI to view our DynamoDB tables

npm install dynamodb-admin -g

export DYNAMO_ENDPOINT=http://localhost:8000

Now run

dynamodb-admin

We should have our table displayed

Configuring serverless.yml for DynamoDB

dynamodb:
    stages: dev
    start:
      port: 8089 
      # set our custom DynamoDB port
      migrate: true
      # creates tables from serverless config
      seed: true 
      #determines which data to onload
    seed:
      domain:
        sources:
          - table: MyDB-dev
            sources: [./resources/seeds/myDB.json]

I published a great cheat sheet with all commands needed for setting up DynamoDB offline you can find it here

https://github.com/codaelux/DynamoDB-offline-doc