サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
災害への備え
engineering.webpay.co.jp
既存商用環境利用者様向け 利用可能期間 決済機能(新規課金、払い戻し、仮売上、実売上等)はいつまで利用できますか? 2017年04月30日までのご利用となります。 APIはいつまで利用可能ですか 2017年4月30日までのご利用となります。 決済機能/API停止後に払い戻しが発生した場合にはどうしたらどうしたらよいですか お手数をお掛け致しますが、購入者への返金手続きは銀行振り込み等の代替手段によってご対応ください。 アカウントページ(課金履歴等の情報含め)が閲覧できるのはいつまでですか 2017年5月31日までとなります。 精算について チャージバック・利用内容調査の対応はいつまでですか 2017年06月以降に発生したチャージバック、利用内容調査につきましては、個別にご案内を差し上げ、精算手続きを実施致します。 商用環境を利用中ですが、サービス終了後に何かあった場合はどこに連絡したらよい
本記事は仮売上(オーソリ)とユーザ体験 - Qiitaの再録です。 Qiitaの方はWebPay Advent Calendar 2013のものであるため当時の状態を維持し こちらの記事では最新の情報に合わせて加筆、編集を加えております。 ユーザのがっかりを無くす 仮売上(オーソリ)を使ったサービス設計を少し具体的なところに落として、活用する方法を探ってみます。 例えば、AmazonなどECサイトでの買い物を思い浮かべてみましょう。 購入の最終確認画面まで辿り着き、無事に購入処理を終えて後は商品を待つだけという気分になり離脱した後にメールで「クレジットカードの情報を修正して下さい」はなかなか辛い思いをするのではないでしょうか。 ECサイトには、カードが何故使えなかったかの明確な理由が必ずしも得られるわけではない(往々にして得ることは出来ません)ため、「カード起因で決済に失敗した」以上の事実
仮売上(オーソリ)を使ったサービス設計 Posted by sowawa Aug 26th, 2014 本記事は仮売上(オーソリ)を使ったサービス設計 - Qiitaの再録です。 Qiitaの方はWebPay Advent Calendar 2013のものであるため当時の状態を維持し こちらの記事では最新の情報に合わせて加筆、編集を加えております。 突然ですが、みなさん、仮売上って知ってますか? 仮売上と通常の売上処理の違いとは一体何なのか、 『仮』という文字が付いている意味をまず解説して活用方法をご紹介したいと思います。 仮売上は、オーソリ(注)などと呼ばれることがあるクレジットカード決済の一つの機能です。 注: オーソリとはauthorization(オーソリゼーション)の略です もともと仮売上やオーソリは、信用照会業務として偽造・盗難カードや期限切れのカードなどの不正利用を防止するた
この夏にWebPayでインターンをしている @toriimiyukki です。 インターン中にセキュリティの調査やテストなどを行い、その成果としてCheckoutHelperのv3をリリースしました。 これまでのCheckoutHelperは、カード情報入力フォームを動的にDOMを生成しページに埋め込んでいましたが、iframeでページに埋め込むよう変更し、ユーザーが直接webpay.jpドメイン内のフォームにカード情報を入力することができるようになりました。 しかし、このバージョンアップではiframeを使えない環境などに依存があるため、既存のCheckoutHelperのv2を更新せず、新たにv3としてリリースをしています。 何が変わったのか これまでのCheckoutHelperは、JavaScriptが読み込まれたページ内にカード情報入力フォームのDOMを生成する仕組みでした。 し
Go言語向けのサーバサイドライブラリ、webpay-goをリリースしました。 これまでRuby、PHP、Java、Python、Node.jsをサポートしていましたが、今後は加えてGo言語でWebPayを利用するサービスを構築できます。 今回のバージョン0.1.0のリリースはベータ版であり、バージョン1.0になるまで、非互換な変更を行う場合があります。 変更した場合、これまでの他の言語のライブラリのリリースと同様、このブログの記事でアナウンスします。 バージョンを更新する際は特に注意して動作確認をお願いします。 また、ベータ版であるため、公式サイトのドキュメントには掲載しておりません。 GoDocやソースコードをご確認ください。 このライブラリのいくつかの機能を確認するプログラムを次に示します。 Goのバージョン1.4で動作確認をしています。 まずライブラリをgo getで取得します。 1
Spree CommerceでWebPayを決済ゲートウェイとして利用するためのSpree Extension、spree_webpayをリリースしました。 今回のリリースはプレリリースであり、今後利用した方からのフィードバックをいただき、正式なリリースを行おうと考えています。 この記事を読んで興味を抱かれた方は、ぜひいろいろ試して、GitHubのリポジトリにフィードバックをお寄せください。 概要 SpreeはRuby on RailsでECシステムを構築するためのライブラリです。 ECシステムへの公式な対応はEC-CUBEについで2つ目となります。 Spreeは拡張の開発が容易な設計になっており、ActiveMerchantに収録されているWebPayのゲートウェイ実装を経由してWebPayを利用することもできました。 しかし、この方法は動作させるだけでもかなりのコーディングが必要であり
ここ数ヶ月にわたって、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を使います。
WebPayでは、オブジェクトに起こったことを時系列で管理するために、イベントオブジェクトを提供しています。 イベントが発生した時にはWebhookによる通知も取得できるので、 定期課金による課金の作成などWebPay上で自動的に起こった変化を簡単に知ることができます。 イベントの処理やWebhookを実装する場合はすべてのイベントをテストしたいものですが、 一部の種類のイベントはどうやったらテスト環境で発生するか、わかりにくいです。 そこで、この記事では今実装されているすべてのイベントを発生させるためのテクニックをお教えします。 特に定期課金オブジェクトをご利用の方に有益な情報です。 以下すべてのイベントの例を掲載していますが、本記事作成時点であり、今後APIの更新によりフィールドが追加される場合があります。 自動テスト用のサンプルレスポンスに使う場合は、必ずテスト環境にリクエストを行い
WebPayは開発者が安心して効率よく開発を進めるための手段として、自動テストを重視しています。 EC-CUBE決済モジュールmdl_webpayの自動統合テストを記述した経験をもとに、 WebPayを利用したアプリケーションをCodeceptionのAcceptance Testでテストする方法を紹介します。 今回は対象のアプリケーションとして、以前の記事、「少しのPHPのコードでWebPayを導入する」で作成したものを利用します。 本記事の内容は、現在の実装に依存したハックを多数含みます。 この記事で説明している内容が将来的にも利用できることをお約束するものではないことをご理解ください。 公式ページのドキュメントで解説している項目以外は、予告なく変更することがあります。 あくまでテストのひとつの方法として、参考にしてください。 SUTを分析する 今回はテスト対象のアプリケーションがすで
他のWebPayユーザに、そのユーザのデータを使ったサービスを提供できる、WebPay Extendを先日リリースしました。 WebPay ExtendはOAuth2に則ったオーソドックスな仕組みで提供されており、扱うオブジェクトも通常WebPayを利用する場合と同一です。 とはいえ、Extendアプリケーションの着想を得にくかったり、細部でどう処理するのが正しいのかわかりにくい箇所もあるでしょう。 そこで、WebPay Extendをすぐに体験でき、実際のサービスの運用にも便利に使えるWebPay Receiptのソースコードを公開しています。 この記事では、WebPay Receiptの機能を紹介し、内部の実装を簡単に説明しながらExtendアプリケーション作成の足掛かりを提供します。 WebPay Receiptを使ってみる WebPay Receiptは、顧客オブジェクトに課金が作
WebPay Extendをリリースしました。 WebPay Extendは、OAuth2による認可を受けることでAPIキーを受け渡すことなく、 認可したユーザのWebPay上のデータを取得したり、課金を発生させるなどの権限を得ることの出来る機能です。 WebPay Extendを用いたアプリケーション(Extendアプリケーションと呼称します)を開発することで WebPayだけでは手の届かなかった細かな機能を、WebPayの利用者自身だけでなく他のWebPayのユーザにも提供することが可能になります。 WebPayの開発者としても、WebPay本体を出来る限りシンプルに保ちたいという意思と、便利な機能を提供したいという意思がせめぎ合っていました。 今後、WebPayのAPIを利用して独自に開発を行っていた方の機能が世に出られるように、ひいては私達が叶えられなかった機能を叶えるために活用し
WebPayはRailsを利用して構築しています。 今回はRailsアプリケーションでちょっと手間取る検索の高速化のTipsを紹介します。 最近のRailsアプリケーションでは、整合性が要求される基本的なデータにRDBMSを、揮発性の高いデータに高速なNoSQLを利用するパターンが一般的です。 WebPayではMySQLとRedisでこのような構成をとっています。 Redisは使い勝手がよく、高速で、データをディスクに保持することができるので、KVS系のNoSQL製品のなかでは一番汎用的に利用できる印象があります。 さて、Railsではserializeを指定して変化しがちなデータ形式をJSON等のシリアライズ形式でRDBにストアすることがあります。 メタデータなど、雑多な入力が予期されるデータには非常に便利ですが、シリアライズされたフィールドを検索しにくいという欠点があります。 Post
PCI DSS PCI DSSはAmerican Express、Discover、JCB、MasterCard、Visaの5つの国際カードブランドが共同で設立したPCI SSCにより策定され3年の周期で基準が改定されています。 2014年1月1日より、PDI DSSの新バージョンである3.0の適用が開始となりました。 WebPayではこれまでPCI DSS v2.0に準拠していましたが、 国際マネジメントシステム認証機構によるオンサイト監査を受け、PCI DSS v3.0に準拠しましたのでご報告いたします。 PCI DSSに関連する法律 クレジットカード情報を取り扱う全ての事業者は、PCI DSSに準拠する必要があります。 米国では、PCI DSS非準拠加盟店がクレジットカード情報を漏洩させた場合の罰則規定を明確化する動きがあります。 既にミネソタ州、ネバダ州、ワシントン州では州法として
こんにちは、sowawaです。 OpenSSHによる二段階認証についての続編記事です。 ワンタイムパスワード(One Time Password: よくOTPと略されます)とは、一回限りの使い捨てのパスワードのことです。認証するサーバ等との間で事前に共有が必要な情報は、 …こんにちは、sowawaです。 OpenSSHによる二段階認証についての続編記事です。 ワンタイムパスワード(One Time Password: よくOTPと略されます)とは、一回限りの使い捨てのパスワードのことです。認証するサーバ等との間で事前に共有が必要な情報は、 アルゴリズムにより様々ですが時間やカウンターをベースにしたものがよく利用されています。 最近では、様々なサービスで同じメールアドレスとパスワードの組み合わせで使い回されたことによって、 ひとつのサービスから流出したパスワードとメールアドレスを他のサービス
皆さん、こんにちはsowawaです。 このEngineering Blogはライブラリのリリースや機能追加の各種お知らせが中心ですが、今日は趣向を変えてOpenSSHによる二段階認証の導入方法について解説します。 PCI DSSという我々の準拠しているセキュリティ基準では、クレジットカード情報の取り扱いに関わるサーバ群へのリモートアクセスに二段階認証の組み込みを要求しているため、WebPayのプロダクション環境を始めとするサーバ群でも認証サーバで二段階認証を実施しています。 OpenSSHで二段階認証を実装する肝となるのは、OpenSSH6.2以降で追加されたMultifactorAuthenticationのためのAuthenticationMethodsというディレクティブです。 参考: http://lwn.net/Articles/544640/ それではさっそく二段階認証を導入し
こんにちは、sowawaです。 OpenSSHによる二段階認証についての続編記事です。 ワンタイムパスワード(One Time Password: よくOTPと略されます)とは、一回限りの使い捨てのパスワードのことです。認証するサーバ等との間で事前に共有が必要な情報は、 アルゴリズムにより様々ですが時間やカウンターをベースにしたものがよく利用されています。 最近では、様々なサービスで同じメールアドレスとパスワードの組み合わせで使い回されたことによって、 ひとつのサービスから流出したパスワードとメールアドレスを他のサービスに対する不正アクセスに頻繁に利用された結果、 重要な情報を扱う様々なサービスではOTPを利用したニ段階認証が導入されるようになりました。 多くの人がアカウントを持っているGoogleでは、Google Authenticatorと呼ばれるモバイル端末等で動作するOTP生成ア
本記事は少しのコードでWebPayを導入する PHP Ver. – Qiitaの再録です。 Qiitaの方はWebPay Advent Calendar 2013のものであるため当時の状態を維持し こちらの記事では最新の情報に合わせて加筆、編集を加えております。 まずはじめに。 少しのRubyのコードでWebPayを導入するはどうでしたか?WebPayの導入がこんなに簡単なのかと思われた方も多かったのではないでしょうか? 昨日はRubyを使った導入例でしたが、本日はさらにたくさんの方に使われているPHPを使ったお話をしたいと思います。しかも、WebPayのドキュメントで前提となっているComposerも不要な導入例を書いていこうと思います。ということで『さらに簡単』を目指し、より手軽で身近なPHPが動くレンタルサーバを対象としています。Herokuが多くのプログラミング言語をサポートしてい
本記事は少しのコードでWebPayを導入する – Qiitaの再録です。 Qiitaの方はWebPay Advent Calendar 2013のものであるため当時の状態を維持し こちらの記事では最新の情報に合わせて加筆、編集を加えております。 決済のコードを出来るだけ少なく ウェブサービスのコードの中で決済に関わる部分に対する開発者の不安を拭うことはとても難しいです。ソフトウェアとして動くというのは勿論、ビジネス上の条件との整合性や 決済に限った話ではないですが、お金を払うお客さんという登場人物が増えるだけで「何か問題があったら…」と膨らむ緊張感は小さくありません。 テストを書くとかプライシングの責任者とのコミュニケーションを密にとか大事なことはいくらでもあるのですが、その中に「決済にまつわるコードを少なくする」というのもあっても良いかもしれません。シンプルで短いコードで無為なミスや変な
WebPayではメインのコミュニケーションに2014年2月よりSlackを使っています。 洗練されたインタフェースとエンジニアフレンドリーな機能をもったすばらしいチャットツールですが、いくつか不便な点があります。 そのうちのひとつが検索の性能の悪さです。 英語の文字列でも全然関係ない結果を返してくることが多く、日本語ではほとんど壊滅的になりますっていました(現在はかなり改善されています)。 Slackを利用している日本のチームはいくつもありますが、おそらく同じ問題で悩んでいるのではないでしょうか。 この問題を解決するために、SSlackというツールを作成しました。 (Slack API: Community Built Integrations | Slackにも掲載されました) SlackからOutgoing Webhookで監視しているチャンネル上の発言を取得し、elasticsear
WebPayはわかりやすいAPI、各言語のライブラリを提供するなどして、開発者の皆様が簡単にペイメント機能を実装できるように努力してきました。 その一環として、実際にWebPayを利用する簡単なRailsアプリケーションを、WebPay Closetの名前で公開しています。 WebPay ClosetはWebPayが推奨するアプリケーションの構築方法を、実際のコードで示したものです。具体的には CheckoutHelperを利用した直接カード番号を取り扱わないサーバサイドプログラミング 顧客オブジェクトによる、カード番号を入力する手間の削減 定期課金機能の利用 テスト環境とテスト用カード番号による開発・ステージ環境での動作チェック WebPayのサーバとの通信をおこなわない自動テスト の要素を盛り込んでいます。 WebPay Closetで実際にWebPayのテスト環境を利用して稼動してい
WebPayでは、エラーが発生したときなどに同一のリクエストを複数回おくったために、おなじリクエストが複数回処理されてしまうことを防ぐために、UUIDを利用してリクエストを識別する仕組みを採用しています。 この仕組みの利用法については過去のQiitaの投稿でも触れていますが、本稿ではあらためてUUIDによるリクエスト識別機能を紹介するとともに、この機能をどのように実装しているかをサンプルコードで紹介していきます。 リクエスト識別機能の利用法と挙動について 本機能は、記事執筆時点で次のオブジェクトを作成するときに利用できます。 課金(Charge) 顧客(Customer) トークン(Token) 定期課金(Recursion) 課金の作成のドキュメントには、UUIDが次のように説明されています。 uuid: 任意 デフォルトはnull RFC4122に準拠したUUID(例:“f81d4fa
iOS向けに、クレジットカードの情報からWebPayのTokenオブジェクトを作成するライブラリを公開しました。 iOS環境上で、端末が直接WebPayとクレジットカードの情報をやり取りし、代替となるトークンを作成することで サーバサイドにクレジットカードの情報を送信することなく、決済処理を実現出来るようになります。 本ライブラリは、CocoaPodsにも公開しており、 ソースコードはgithubにてMITライセンスで公開しています。 WebPayの公開可能鍵を与えることで、クレジットカードをトークン化する部品に加えて クレジットカード情報の入力用フォームや、モーダルで表示できるビューコントローラを用意しています。 webpay-token-iosの使い方 インストール CocoaPodsを使った方法(推奨)と、手動でコピーする方法があります。 CocoaPodsを使ってインストール Po
決められた周期で自動的に課金を行うためのオブジェクト、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
このページを最初にブックマークしてみませんか?
『WebPay Engineering Blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く