APIのエラーハンドリングを見直そう - WebPay Engineering Blog
ここ数ヶ月にわたって、WebPayはAPIのエラーにまつわる変更を少しずつ行ってきました。 それに付随してドキュメントも拡張しましたが、変更の背景について十分に説明できていない部分がありました。 この記事では、最近のエラーに関連した変更の背景を紹介し、今後どのようにエラーをハンドルすべきか説明します。 記事の内容は執筆時点のものであり、今後同じようにエラーやAPIの変更を行うことがあります。 変更があっても記事の内容はその時点の内容を保持し、ウェブサイトのドキュメントのみ更新します。 必ずウェブサイトのドキュメントを合わせて参照し、手元で動作確認を行ってください。 エラーはなぜ起きるのか WebPayのAPIは、リクエストされた操作ができなかったときにエラーを返すように設計しています。 可能なかぎりエラーにならないような設計、実装を心がけていますが、エラーは絶対に避けられません。 例えば、
OpenSSHによる二段階認証について ワンタイムパスワード編 - WebPay Engineering Blog
こんにちは、sowawaです。 OpenSSHによる二段階認証についての続編記事です。 ワンタイムパスワード（One Time Password: よくOTPと略されます）とは、一回限りの使い捨てのパスワードのことです。認証するサーバ等との間で事前に共有が必要な情報は、 アルゴリズムにより様々ですが時間やカウンターをベースにしたものがよく利用されています。 最近では、様々なサービスで同じメールアドレスとパスワードの組み合わせで使い回されたことによって、 ひとつのサービスから流出したパスワードとメールアドレスを他のサービスに対する不正アクセスに頻繁に利用された結果、 重要な情報を扱う様々なサービスではOTPを利用したニ段階認証が導入されるようになりました。 多くの人がアカウントを持っているGoogleでは、Google Authenticatorと呼ばれるモバイル端末等で動作するOTP生成ア
少しのRubyのコードでWebPayを導入する - WebPay Engineering Blog
本記事は少しのコードでWebPayを導入する – Qiitaの再録です。 Qiitaの方はWebPay Advent Calendar 2013のものであるため当時の状態を維持し こちらの記事では最新の情報に合わせて加筆、編集を加えております。 決済のコードを出来るだけ少なく ウェブサービスのコードの中で決済に関わる部分に対する開発者の不安を拭うことはとても難しいです。ソフトウェアとして動くというのは勿論、ビジネス上の条件との整合性や 決済に限った話ではないですが、お金を払うお客さんという登場人物が増えるだけで「何か問題があったら…」と膨らむ緊張感は小さくありません。 テストを書くとかプライシングの責任者とのコミュニケーションを密にとか大事なことはいくらでもあるのですが、その中に「決済にまつわるコードを少なくする」というのもあっても良いかもしれません。シンプルで短いコードで無為なミスや変な
定期課金を行うオブジェクト Recursion を追加しました - WebPay Engineering Blog
決められた周期で自動的に課金を行うためのオブジェクト、Recursionが追加されました。 Recursionオブジェクトを利用することで、これまで独自にバッチ処理などで実装する必要があった定期的な課金処理を代替できるようになりました。 Recursionオブジェクトは 定期的に課金する価格（と通貨） 対象となるCustomer 課金を引き起こす周期（毎月or毎年） を指定して作成すると、作成時から指定された周期で課金を行います。 毎月400円の定期課金をcus_7517t5eEOg04grEがidである顧客に設定する場合は以下のようになります。 1 2 3 4 5 6 7 8 9 require "webpay" WebPay.api_key = "test_secret_6Uz2yNdNA6cpeSW4X4cB5aSh" WebPay::Recursion.create( amount
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
