東京にいるfukuokaexのYOSUKEこと中尾瑛佑です。
今回は、PAY.JPについて記事を書くことにしました。早速アカウントを登録してドキュメントを確認したところ、UIの第一印象は「使いやすそう」でした。
ダッシュボードには、課金に関する必要最低限の情報が一目で分かるように整理されています。
この好印象な出だしに油断はできません。一般的に、開発に必要なドキュメントの整備や内容の質が重要だからです。ドキュメントを確認すると、これも読みやすく整理されていました。
ビジネス側の意図として、開発者を主なターゲットに、使いやすさを重視している様子が伺えます。課金周りの開発で有名なStripeやSquareの導入に苦戦している開発者向けに、より直感的な課金の仕組みを提供することを目指しているようです。
気になってホームページ （ https://pay.co.jp/ ) を見てみると、目に飛び込んできたのは：
「支払いのすべてをシンプルに」
素晴らしいキャッチコピーと、それを実現するプロダクト。
開発チームとビジネスチームの連携が上手く機能している印象です。アジャイル教育に携わる身として、アジャイルな組織運営をしているのではと興味をそそられます。
ここまでは順調でしたが、重大な問題を発見しました。curl、Python、Ruby、PHP、Node.js、Java、Goはサポートされているのに、Elixirのライブラリがないのです！
これは作るしかありません。
支払いのすべてをシンプルに
Elixir用の薄いラッパーを作ろうと思い立った際、このキャッチコピー「支払いのすべてをシンプルに」が頭をよぎりました。
Elixirのライブラリも、このコンセプトに沿って作る必要があります。
現在のライブラリの構成を確認してみましたが、すべての機能を実装しようとすると、ややブログが長編になるのでシリーズ化します。
そのため、この記事では完成を目指すのではなく、段階的に実装を進めていくことにします。
Elixirでサービスを作りたい方向けに、GitHubでMITライセンスのオープンソースとして公開します。普段はGitLabを使用していますが、オープンソースのリポジトリはGitHubの方が多くの方に利用していただきやすいと考えました。
curlで試す
まずは動作確認のため、curlでAPIを呼び出してみます
curl https://api.pay.jp/v1/charges \
> -u sk_test_YOUR_API_KEY
Enter host password for user 'sk_test_YOUR_API_KEY':
{
"count": 0,
"data": [],
"has_more": false,
"object": "list",
"url": "/v1/charges"
}%
この秘密鍵を使って取得できるJSONデータを、Elixirで扱いやすい形で取得できるシンプルな実装を目指します。ただし、記事が長くなりすぎるのを避けるため、詳細な実装はElixirのアドベントカレンダーで紹介させていただきます。
改善点について
エンジニア教育や教材作成に携わる立場から、いくつか気になる点を見つけました。「支払いのすべてをシンプルに」というコンセプトに沿って、改善案を提案させていただきます。
APIキーの表記について、現在は「テスト秘密鍵」「テスト公開鍵」という表現が使われています。一方、ドキュメントでは「テスト用のキー」や「パブリックキー」「シークレットキー」といった異なる表現が混在しています。
この「表記揺れ」は、特に初心者の方々に混乱を招く可能性があります。また、JSONオブジェクトの項目順序とドキュメントの解説順序に不一致が見られるなど、細かな改善の余地があります。これらの点を統一することで、より「シンプル」なドキュメントになるでしょう。
コンテンツディレクターをチームに加えることで、これらの課題に対応できるかもしれません。課金系サービスとして、StripeやSquareと差別化を図る上で、分かりやすい日本語のドキュメントは重要な競争力になると考えます。
最後までお読みいただき、ありがとうございます。続きはElixirのアドベントカレンダーで紹介していきますので、興味のある方はぜひそちらもご覧ください。
ElixirでPAY.JPのライブラリ作成シリーズ①