はてなブックマーク

仮売上（オーソリ）を使ったサービス設計 Posted by sowawa Aug 26th, 2014 本記事は仮売上（オーソリ）を使ったサービス設計 - Qiitaの再録です。 Qiitaの方はWebPay Advent Calendar 2013のものであるため当時の状態を維持し こちらの記事では最新の情報に合わせて加筆、編集を加えております。 突然ですが、みなさん、仮売上って知ってますか？ 仮売上と通常の売上処理の違いとは一体何なのか、 『仮』という文字が付いている意味をまず解説して活用方法をご紹介したいと思います。 仮売上は、オーソリ（注）などと呼ばれることがあるクレジットカード決済の一つの機能です。 注: オーソリとはauthorization（オーソリゼーション）の略です もともと仮売上やオーソリは、信用照会業務として偽造・盗難カードや期限切れのカードなどの不正利用を防止するた

ここ数ヶ月にわたって、WebPayはAPIのエラーにまつわる変更を少しずつ行ってきました。 それに付随してドキュメントも拡張しましたが、変更の背景について十分に説明できていない部分がありました。 この記事では、最近のエラーに関連した変更の背景を紹介し、今後どのようにエラーをハンドルすべきか説明します。 記事の内容は執筆時点のものであり、今後同じようにエラーやAPIの変更を行うことがあります。 変更があっても記事の内容はその時点の内容を保持し、ウェブサイトのドキュメントのみ更新します。 必ずウェブサイトのドキュメントを合わせて参照し、手元で動作確認を行ってください。 エラーはなぜ起きるのか WebPayのAPIは、リクエストされた操作ができなかったときにエラーを返すように設計しています。 可能なかぎりエラーにならないような設計、実装を心がけていますが、エラーは絶対に避けられません。 例えば、

WebPayはサーバインフラの大部分でAWSを利用しており、クラウドサービスもAWSのものを好んで利用しています。 今回、新たにカード会員データを取り扱う部分を再構築するにあたり、AWS Key Management Serviceについてサーベイしました。 この記事ではその過程で得られた知見を、PCI DSSとの関係や実際のコードに触れながら紹介します。 カード決済に限らず、セキュリティが重要なシステムを構築しているエンジニアに是非読んで欲しい内容になっています。 AWS Key Management Serviceとカード会員データ AWS Key Management Service（以後KMS）は、端的にはデータの暗号化、復号化を実施するサービスです。 具体的な利用法や特徴については公式ドキュメント What is the AWS Key Management Service?に譲

WebPayは現在、Apple Payへの対応を進めています。 Apple PayではElliptic Curve Cryptographer（ECC、楕円曲線暗号）が用いられるという事前の情報に基づき、Elliptic Curve Integrated Encryption Scheme (ECIES)の実装を行いました。 結局、Apple Payで送信される暗号文はECIESの形式を満たすものではなかったため、そのまま利用することはできませんでしたが、 この実験を通じて得た知見をもとにテンポよく実装を進めることができました。 本記事はその知見を共有することを目指して、ECIESについて簡単に説明したあと、 実験的に実装したRubyライブラリ、openssl-pkey-ec-iesを紹介します。 ECIESとは Elliptic Curve Integrated Encryption S

以前、Slackの検索機能を強化するSSlackをリリースしましたが、今回は引き続き、アプリケーションからSlackへの投稿を円滑にするSlack Anywhereを公開しました。 本記事では、その開発の経緯や使い方を説明します。 開発の背景 WebPayは私を含め、遠隔地で勤務しているメンバーが多いため、ChatOpsを積極的に取り入れています。 Slackは多くの外部ツールと簡単にインテグレートできる点でChatOpsにぴったりです。 しかし、用意されているものでは不満が出てくるのが技術者の性です。 導入当初から、より自分たちのオペレーションにマッチした機能に改良し、業務を効率化するために連携機能の開発をすすめてきました。 Slackに繋ぎこむサービスをつくるのではなく、手製ツールからSlackに通知を飛ばす場合、おもにIncoming WebHooksとSlack APIを使います。

こんにちは、sowawaです。 OpenSSHによる二段階認証についての続編記事です。 ワンタイムパスワード（One Time Password: よくOTPと略されます）とは、一回限りの使い捨てのパスワードのことです。認証するサーバ等との間で事前に共有が必要な情報は、 アルゴリズムにより様々ですが時間やカウンターをベースにしたものがよく利用されています。 最近では、様々なサービスで同じメールアドレスとパスワードの組み合わせで使い回されたことによって、 ひとつのサービスから流出したパスワードとメールアドレスを他のサービスに対する不正アクセスに頻繁に利用された結果、 重要な情報を扱う様々なサービスではOTPを利用したニ段階認証が導入されるようになりました。 多くの人がアカウントを持っているGoogleでは、Google Authenticatorと呼ばれるモバイル端末等で動作するOTP生成ア

本記事は少しのコードでWebPayを導入する – Qiitaの再録です。 Qiitaの方はWebPay Advent Calendar 2013のものであるため当時の状態を維持し こちらの記事では最新の情報に合わせて加筆、編集を加えております。 決済のコードを出来るだけ少なく ウェブサービスのコードの中で決済に関わる部分に対する開発者の不安を拭うことはとても難しいです。ソフトウェアとして動くというのは勿論、ビジネス上の条件との整合性や 決済に限った話ではないですが、お金を払うお客さんという登場人物が増えるだけで「何か問題があったら…」と膨らむ緊張感は小さくありません。 テストを書くとかプライシングの責任者とのコミュニケーションを密にとか大事なことはいくらでもあるのですが、その中に「決済にまつわるコードを少なくする」というのもあっても良いかもしれません。シンプルで短いコードで無為なミスや変な

WebPayではメインのコミュニケーションに2014年2月よりSlackを使っています。 洗練されたインタフェースとエンジニアフレンドリーな機能をもったすばらしいチャットツールですが、いくつか不便な点があります。 そのうちのひとつが検索の性能の悪さです。 英語の文字列でも全然関係ない結果を返してくることが多く、日本語ではほとんど壊滅的になりますっていました（現在はかなり改善されています）。 Slackを利用している日本のチームはいくつもありますが、おそらく同じ問題で悩んでいるのではないでしょうか。 この問題を解決するために、SSlackというツールを作成しました。 （Slack API: Community Built Integrations | Slackにも掲載されました） SlackからOutgoing Webhookで監視しているチャンネル上の発言を取得し、elasticsear