決済システムを壊さずに拡張した話 | メルカリエンジニアリング
メルペイのBackend Engineerの @Hiraku です。与信決済システムのmicroserviceのTech Leadをしております。 この記事は、Merpay Advent Calendar 2022 の5日目の記事 メルカードの舞台裏編です。 2022年11月8日にメルペイ初のクレジットカードであるメルカードがリリースされました。これに伴い、システムにも広範囲に変更が加わっています。この記事ではその中でもちょっと分かりにくい、メルペイスマート払いの請求タイミングの変更について解説します。 月末ごろにメルカードによる決済を行うとわかるのですが、「処理中」と表示され、翌月の請求に含まれないものがあります。こちらはメルカード特有の実売上処理が終わってから請求する挙動です。順番に解説していきます。 カード決済の流れ 決済は大きく2段階の処理で成り立っています。「オーソリ」や「仮売上
決済チームがテストコードを書く際に気を付けていること - UPSIDER Techblog
こんにちは。決済チームでエンジニアとして働いている芦川です。 UPSIDER Tech blog 第2弾として「決済チームがテストコードを書く際に気をつけていること」を紹介しようと思います。 TL;DR 100％のテストカバレッジを目指す テストはブラックボックスを優先して記述、どうしても到達できない場合はホワイトボックス 最初のテストケースは、テスト対象が動作する最も一般的なケースであるべき 私たちは日々大量のコードを書いており、そのシチュエーションは多岐にわたります。 そういった環境において、動作確認からのコード改修のコストを考えた場合、自動テストの有無によって生産性に大きく差が出ることは容易に想像ができます。また、既存のサービスに改修を加えるために、そのサービスの概要を把握したい場合、良いテストコードはドキュメントとして役立ちます。 以前、私はテストコードを一切書かないプロダクトの開
マイクロサービスにひそむ複雑さに立ち向かう - Qiita
はじめに はじめまして。Kyashでサーバサイドエンジニアを担当しているhirobeです。 Kyash Advent Calendar 2021の12/5担当分です。 Kyashでは、約30ほどのマイクロサービスが動いてます。 マイクロサービスは難しいです。 私が入社して2年半ほどの間、マイクロサービスの複雑さに苦しめられ、あがいてきた実経験をもとに、マイクロサービスにひそむ難しさを紹介したいと思います。 ここでは、ケースとして、弊社の機能のひとつである登録カードからのリンクを実装する上で発生する問題を紹介したいと思います。もちろん弊社サービスを使ったことない人でもわかるように説明をしますのでご安心ください。 なお、最初に注意書きしておくと、本ブログではあくまで「マイクロサービスにひそむ複雑さとその対応法」を説明するためのわかりやすさを優先して説明していきます。事実とは異なるケースがありま
マイクロサービス分割点の見つけ方 | MoT Lab (GO Inc. Engineering Blog)
こんにちは、SREグループの水戸 (@y_310) です。MoTでは多種多様なマイクロサービスが稼働しています。マイクロサービスは一般的に、あるプロダクトを何らかの形で分割した内の一部の役割を担うものです。その分割されたマイクロサービスにおいてどこまでをそのサービスの責務とし、どの役割を含めてどの役割を含めないか、という他のサービスとの適切な境界を見つけることは非常に重要です。SREグループでは多くのマイクロサービスのアーキテクチャ設計に関わりながらマイクロサービスの分割点についての知見を得てきました。この記事では実例をベースにマイクロサービスの分割点の見つけ方について書きたいと思います。 単機能のサービスビジネスロジックとの依存度が低い単機能かつ汎用的な機能は、データストアとの依存性も低く比較的容易に単体のサービスとして切り出すことができます。 分割点の目印データストアへの依存が無いデー
上原＠株式投資家 on Twitter: "クレジットカード業界の収益構造を図でまとめてみました。 ①消費者がカードで買い物をする ↓ ②加盟店がアクワイアラとイシュアに3.24%の手数料を支払う（イシュアの取り分は2.3%） ↓ ③アクワイアラとイシュアがカードブラ… https://t.co/60N0AYAqZr"
クレジットカード業界の収益構造を図でまとめてみました。 ①消費者がカードで買い物をする ↓ ②加盟店がアクワイアラとイシュアに3.24%の手数料を支払う（イシュアの取り分は2.3%） ↓ ③アクワイアラとイシュアがカードブラ… https://t.co/60N0AYAqZr
BOOTHの“決済スパイク”を防げ！ 創作物の総合マーケットを支えるトランザクション分割
「PIXIV DEV MEETUP 2021」は、完全招待制のオンラインカンファレンスです。ライブセッションをはじめ、さまざまなイベントを通して、ピクシブのメンバーとピクシブのプロダクト開発における知見、組織文化を共有します。金川氏は、「BOOTH」で発生する決済スパイクに対する取り組みについて発表しました。 突然の決済スパイクに悩まされていた「BOOTH」 金川祐太郎氏（以下、金川）：「オンライン即売会を支えた技術」。BOOTH部の金川がお話します。よろしくお願いします。 「BOOTH」では、突然の決済スパイクに頭を抱えていました。決済スパイクは、例えば有名なクリエイターの期間限定販売や、「YouTube」などVTuberの配信中に商品が公開された時、あとは最近行われるエアコミケといったオンライン即売会などで発生します。 決済スパイクが起きる時、BOOTHでは同じ商品に注文が集中します。
決済システムの残高管理周りの DB 設計と戦略 - カンムテックブログ
エンジニアの佐野です。今日はカンムの決済システムでユーザの残高管理をどうやっているかについて書きます。 カンムの製品であるバンドルカードはプリペイド方式のカードです。ユーザによる入金、店舗での利用、運営事由の操作などによりユーザの残高が増減します。このような残高の管理について単純に考えると user_id と balance と updated_at あたりをもったテーブルを用意して balance と updated_at を更新していく方法があるかもしれません。しかしながらカンムでは残高を管理するテーブルを持たず、これらイベントの履歴のみで残高を管理しています。以下、本記事ではこれらユーザの残高が増減するイベントのことをトランザクションと呼びます。ここでは DB の Transaction Processing を意味しません。 本記事のポイントは 残高を管理をするテーブルは作らず、ト
PayPayがAWSを使い続ける理由 日本No.1のQR決済サービスを支えるインフラ構成
ZOZO×一休×PayPay AWS Nightは、2020年7月22日に開催されたZOZOテクノロジーズ・一休・PayPayの3社による合同イベントです。各社それぞれAWSの活用事例を紹介します。PayPay株式会社プラットフォームチームの西中氏がPayPayのインフラの概要について話しました（記事内の情報はイベント開催時点のもの）。 日本のNo.1 QRコード決済サービス 西中智樹氏（以下、西中）：「PayPayでのAWS活用事例について」と題して、PayPay Platformチーム・西中が発表いたします。 簡単に自己紹介します。西中智樹と申します。2018年12月よりPayPayで仕事をしていまして、現在、AWSなどのPayPayのインフラを所管するPlatformのチームに所属しています。好きなAWSサービスはEKSです。 本日のセッションのアジェンダになります。この順番でお話を
決済サービスを閉じるときのやることリスト | メルカリエンジニアリング
Merpay Advent Calendar 2020の20日目は、メルペイProduct EngineeringチームのVP of Engineeringを担当しているnozaqがお送りします。 2020年はメルペイEngineeringチームとして業務しながら、一方で年初からOrigami PayというQRコード決済サービスの提供終了に伴うシステム停止業務を計画・実行してきました。サービスの終わらせ方について詳しく説明されることは中々ないと思ったので、本投稿では決済という外部影響が大きい種類のサービスを終了するにあたり、どのような検討がなされたのかを事例としてお伝えできればと思います。 取り組んだこと 決済サービスはお支払いを行う一般のお客さま・お支払いを受け付ける加盟店様・システム連携している金融機関様やパートナー様など多くのステークホルダーが存在します。また店頭でのお支払い方法をご
CloudNativeな決済サービスの開発と2年間の歩み #sf_A4
Spring Fest 2020 CloudNativeな決済サービスの開発と2年間の歩み SBペイメントサービスではSpringとTanzu Application Serviceを使用して、決済システムを運用、開発しております。 以前SpringFest2018で登壇した際は、プロダクション環境で稼働するまでのストーリーをご紹介しましたが、今回はその後の運用や開発についてお伝えしたいと思っています。 本セッションでは導入の背景や、Spring Boot/Cloudを利用したアーキテクチャの説明、CI/CDやロギング・モニタリング、高レジリエンスへの取り組み内容を改めてご紹介します。 またプラットフォームの導入が開発や運用にどのような効果をもたらしたのか、プロダクションでの運用を安定化させるために行ってきた施策や、運用/開発する中で発生した事象とその対処についてもご紹介する予定です。 #
モノリスからマイクロサービスへの設計の切り替え方 - Qiita
この記事はGLOBIS Advent Calendar 2020の9日目の記事です。 こんにちは、@yohira_devです。 数年前からグロービスの開発案件に参画させていただいています。「智将は務めて敵に食む」という言葉がありますが、今回はグロービスのAdventCalanderで記事を書かせていただきます。 今回のAdventCalanderでは、「モノリスからマイクロサービスへの設計の切り替え方」について、書いていきたいと思います。 この記事を読むべき人 「マイクロサービスってなんか良さそう！うちもとりあえず導入してみようかな...」と思っている人 モノリスでは起こらなかったデータ不整合に消耗している人 モノリシックアプリケーションとマイクロサービスの違い モノリシックなWebアプリケーションを書いている感じで「手なりで」マイクロサービスを実装すると思わぬ落とし穴に嵌ることがあります
ニコニコで12年運用した決済システムを移行する上で必要だったこと - Qiita
はじめに 今日は、ニコニコのプレミアム会員サービスを支える「プレミアム課金システム」を動画システムのモノリスから切り出し、変更可能にしていった過程について書きます。プレミアム課金システムは金銭を扱うシステムですので、「（特に、失敗した）話を聞くのは面白いけど、自分で触りたくない」と思われる方も多いのではないでしょうか。 この記事では、決済にかかわるシステムでも一般的なシステム改善の方法が適用できることをお伝えしたいと思います。また、コストを抑えつつ着実なシステム改善を行う方法論としてもご理解していただけると嬉しく思います。 背景 プレミアム会員サービスについて 月額500円（税別）のプレミアム会員制度には159万人（2020年9月末現在）の方が加入してくださっており、ニコニコ事業を支える主要な有料サービスです。 ニコニコ動画は2006年にサービスを開始し、2007年にプレミアム会員サービス
マイクロサービスにおける決済トランザクション管理 | メルカリエンジニアリング
この記事はMERPAY TECH OPENNESS MONTHの15日目の記事です。 こんにちは。メルペイのPayment PlatformチームでPaymentServiceの開発を担当するエンジニアの @foghost です。 メルペイではマイクロサービスのアーキテクチャで決済システムを開発しています。その中でPaymentServiceは決済トランザクション管理の基盤サービスとして、下位層のサービス（外部サービスも含め）が提供する各種決済手段を利用して、上位層のサービス（メルカリ、NFC，コード払いなど）に必要な決済フローを共通APIとして提供しています。PaymentServiceが提供する決済処理に複数のサービスを跨いでお金の動きを正確に管理する必要があるので、作り始めた頃から決済トランザクション管理を最も重要な課題として、サービスを跨いでもデータの整合性が取れる仕組みを作ってき
ローカル開発環境のために外部サービスをモック化する - BASEプロダクトチームブログ
BASE の Service Dev にて主に決済周りのバックエンド開発をしている翠川（@midori44）です。 昨年は PayPal決済の導入 のプロジェクトでメインエンジニアとして携わらせていただきました。 今回は決済周りの開発をしていく中で、社内の開発環境を整えた話をします。 ローカル開発環境での課題 BASEでは現在、BASEかんたん決済 として6つの決済方法を提供しています。 日々の機能開発をしていく中で、すべての決済方法において各機能が正しく動作するかを確認するために、ステージング環境や社内検証用のQA環境だけでなく開発者のローカル環境でも決済をテストできるようになっています。 新機能のリリース時にはもちろん本番環境で実際の決済を通して動作確認するわけですが、開発中のテストの度に本番相当の決済をするわけにはいかないので、各決済代行会社様のほうで用意していただいている検証用サー
【レポート】楽天の大規模決済システムを支えるAWSアーキテクチャ #AWSSummit | DevelopersIO
DA事業本部の春田です。 AWS Summit Online絶賛開催中！ということで、本記事では「CUS-65: ペイメントプラットフォームにおける AWS の活用」の内容についてまとめていきます。 セッション情報 楽天株式会社 グローバルテクノロジー統括部 國谷 彩 氏 AWS上でのPayment Platformシステムの歴史についてお伝えします。AWSへ移行してからこれまでの課題と解決方法について説明します。 ※セッション動画は以下リンク アジェンダ 楽天グループについて ペイメントプラットフォームについて ペイメントプラットフォームにおけるアマゾンウェブサービス（AWS）の歴史 楽天グループについて Eコマースのサービス「楽天市場」をはじめ、Fintech事業やエンターテイメント事業まで、さまざまなビジネスを展開 各サービスが楽天共通IDで繋がることで、サービスを跨いだグループシナ
高木浩光＠自宅の日記 - テレフォンバンキングからのリバースブルートフォースによる暗証番号漏えいについて三井住友銀行に聞いた
■ テレフォンバンキングからのリバースブルートフォースによる暗証番号漏えいについて三井住友銀行に聞いた 先週から、「ドコモ口座不正引き出し事件」の原因として、被害の発生した銀行が4桁数字の暗証番号で認証処理していたことが取りざたされており、リバースブルートフォース攻撃の手口が暗証番号特定の手段として使われた可能性について、テレビのワイドショーでも扱われるなど、世間での認知がかつてなく高まっている。 そこで、この機会に、昔から存在していたテレフォンバンキングの危険性について、銀行側に抗議すれば今ならご理解いただけるのではないかと考えた。この問題は十数年前にも銀行側に伝えているが、サービスを止めるわけにもいかないし、電話経由での自動処理による攻撃は考えにくいと当時は考えられたのか、対処されることはなかった。2020年の今日、電話経由のサイバー攻撃は技術面で十分に容易に可能となっていると考えられ
クレジットカードのオーソリゼーションのお話。 - メモ代わりのブログ
この記事を見かけたので。 naoki440.info TL;DR ・オーソリゼーション（仮売上処理、「オーソリ」）の有効期限は最大60日間と定められている為、60日を超過するとオーソリゼーションが無効になり、売上が非成立となる。 ・予約商品では60日以内に再度オーソリを行うことで、実質的に決済の有効期限を延長している。 ・Lenovoが一回目のオーソリ返金完了前に再度オーソリを行ったのは正常な挙動。 ・クレジットカードの場合、オーソリではなく売上確定処理後に請求を行う為、この問題は発生しない。 ・Kyash側で2重に引き落としされた＆チャージ元クレジットカードへ返金ができないのは正常な挙動。 ・クレジットカードのシステムにプリペイドを突っ込むとこの挙動になってしまう。つまり仕様と言える（各種プリカ発行会社もユーザーに告知している）。 一般的なカード決済の流れについて オーソリゼーション（仮
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
shiodaifuku.io
shiodaifuku.io