Open toshi0607 opened 10 years ago
toshi0607
commented
10 years ago ●調べながら思ったこと 選択基準は次のようになるのではないか。 【開発者目線】 ・言及しているWebページが多い 情報がオープン 開発者が多い ・開発者向けの雑誌に載ってる 本にするだけ事例が多い 取り組みやすい ・サイトに開発に必要な情報が整理されている 調べ辛いとイライラする それ探すのに労力かけるのは違う 【ユーザ目線】 ・登録が楽 毎回情報入力しないといけない？項目は多い？ ・安心 カード情報、その他のユーザ情報はCoffreが保持しない ・決済手段 カード以外にもコンビニ支払いとかあった方が便利？カード情報の入力に抵抗がある人は多いらしい…
【総合】 ・必要なAPIがそろっている 何が必要か見極めも…
ms2sato
commented
10 years ago @toshi0607 すげー調べてくれてる！この短時間でよく調べているなぁ。
→これで全体感見てから細かく入った方がよいかもしれません http://www.amazon.co.jp/WEB-DB-PRESS-Vol-76-五十嵐/dp/4774158747
購入決定！別途メッセージします。
・必要なAPIがそろっている 何が必要か見極めも…
ここが最も大事ですね。必要な機能が無いAPIを調べても最後導入できません。 さて、必要な機能は何だったでしょうか？ここの整理ができているか気になりまーす。
toshi0607
commented
10 years ago （編集中）
本を読んでイメージがもう少し具体的になったので、報告も見据えてまとめます。大前提の追記です。必要機能の有無調査が肝と意識はしつつ…
『WEB+DB PRESS vol.76 特集2Web決済入門より』 ●決済手段 p44 ①クレジットカード ②携帯電話キャリア決済 ③プリペイド（代替マネー購入、電子マネー利用） ④コンビニ決済 ⑤代金引換 ⑥銀行振込、電子収納、現金書留
●決済手段と決済代行サービスの対応 p45 ・PayPal：クレジットカード ・GMOペイメントゲートウェイ：①〜⑤など ・Veritrans：①③④など ・イーコンテキスト：①②③④ ・WebPay：① ・iOS、OS X内アプリ課金：①③（iTunesCard） ・Android内アプリ決済：①②
●Web決済動向 p46 ・クレジットカード決済が国内インターネット決済の約57.7%で利用されている。（平成25年） 26年になって60％に増加。 http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h25/html/nc243140.html
●加盟店審査 p50 ・クレジットカード決済の導入時には、運営社が会社であっても個人であっても、アクワイアラ（ECサイトなどの加盟店を管理している会社）や決済代行サービスによる加盟店審査を経て、加盟店契約を結ぶ必要がある。 →特定商取引法に準拠することが最重要とのこと。中でも「広告の表示義務」「誇大広告の禁止」「顧客の意に反して契約を申込させようとする行為の禁止」がチェックポイント。APIが基本的にECサイトでの金銭授受を想定している（はず）なので、Coffreでどこまで必要かは不明。いずれ考慮しないといけないとは思いますが、どの段階で調査するかは別途相談させてください。
●セキュリティ要件 p55〜 ・情報漏洩のリスクが大きく、情報の保存時、処理時、伝送時の各経路で対策を講じる必要がある。 →サーバサイドでトークン化することで「保存」を回避、クライアントサイドでトークン化することで「処理」「伝送」を回避。リソースがそこまで無い場合、いかにしてサービス内でリスクポイントを持たないようにするかが大事。
●セキュリティ標準 ・PCI DSSというクレジットカード情報漏洩防止の国際セキュリティ標準があり、12の大項目（http://www.atmarkit.co.jp/fsecurity/special/126pcidss/pcidss02.html）と288の詳細項目が定められており、遵守する必要がある。 http://www.jcdsc.org/pci_dss.php https://ja.pcisecuritystandards.org/_onelink_/pcisecurity/en2ja/minisite/en/docs/PCI_DSS_v3.pdf
・タイプ別必要準拠項目数 A：カードを提示しないWebサービスやアプリケーション（全てのカード会員データ機能を外部委託） 「処理」「伝送」「保存」を全て外部委託 →13 B：クレジットカード情報を電子形式で保存せず、オフラインでインタプリタというカードのエンボス文字を転写する器具またはスタンドアローンのダイアルアップのターミナルのみを利用する店舗 オフラインでクレジットカードを使用する店舗 →29 C-VT：VTはVirtual Terminal（仮想端末）の略で、Webベースの仮想端末を使用し、カード会員データを電子形式で保存しないオフラインの店舗 オフラインでクレジットカードを使用する店舗 →51 C：ペイメントアプリケーションシステムがインターネットに接続されており、カード会員データを電子形式で保存しないWebサービスやアプリケーション 「処理」「伝送」のみを行っている場合 →80 D：そのほかすべてのアプリケーション 「保存」もしている場合 →288
→Aを目指しましょう。トークンを使わずにカード情報を送信する場合Bになってしまう。
ms2sato
commented
10 years ago ちょいと情報足しておくと今回やっているアプリだと
の2点がお金の動きですよね。調べている内容と見比べておいてくだされ。
toshi0607
commented
10 years ago @ms2sato ありがとうございます！ 書いていただいた2点のお金の動き、確認します。 今のところ2点（ユーザA→サービス、サービス→ユーザB）はできそう（PayPalなら画面つき、htmlをちょっといじる感じで実装できそう）なのですが、 ・ユーザがお金の動きを制御する 例えば、ユーザAがユーザBを最終的な入金先としてサービスに送金したら、自動的にユーザBに入金されてしまわないようにする。つまり、次の二点 ・サービスに入金してユーザBに入金されない状態を保持できる ・サービスからBへの入金をユーザAとユーザBのアクション（ボタンクリック=鍵をさす）で制御する という部分が通常の決済系APIの使い方と大きく異なる部分だと思うので、ここをちゃんと調べます。 ただ、この処理ってAPIで対応できてないとダメなものなのか、APIの状態制御はAPIを使う人が何とかするものなのか切り分けられないなぁと思っているので、一番相談させていただきたい点です。
ms2sato
commented
10 years ago @toshi0607 トークンについて僕も調べてみたいので、可能なら書籍の該当部分が読みたいです。PDF化するとかは大変そう？
ms2sato
commented
10 years ago トークンって下記で言うIDトークンを指しているようにも思う。ようはクレジットカード情報をcoffreが保存しないための様々な方法があるので、Paypal任せでセキュリティレベルは高まりますよ、って理解ではないかなと想像しています。詳しくは本を確認したいけど。 http://www.cmswp.jp/plugins/net_shop_admin/net_shop_admin_paypal/
その下のクレジットカードの情報漏洩防止の話は、基本は自社サーバでクレジットカード情報を保存する場合の決まりなので、今回はPaypalに任せるつもりだから特別機にする必要が無いだろう、というのが今の僕の把握です。
あと、サンプルアプリケーション探して何か軽く動かそうとしてみると理解が早そう。 何がしかサンプルコード的なものはありそうでしたか？
toshi0607
commented
10 years ago アダプティブペイメント
●Adaptive Payments API公開でPayPal送金システムをアプリに簡単に組み込めるようになる http://jp.techcrunch.com/2009/07/24/20090723the-online-payment-wars-continue-paypal-officially-announces-flexible-api/
●イメージ図 http://www.slideshare.net/devsumi/16e2 29〜31
●前提条件 http://tategakibunko.hatenablog.com/entry/20110429/1304037866 ・ビジネスアカウント必須（パーソナルでもプレミアでも駄目） ・本番環境で運用するには、アプリケーションID をX.comから取得する必要がある ・Chainned Payments のような処理（Advanced Serviceと呼ばれている）をするには、PayPalの事前審査が必要
・PayPalの事前承認なしに使える機能 ・シンプルとパラレルペイメント（送金者の明示的な承認を必要とするもの） ・支払い詳細取得 ・払い戻し ・通貨換算（両替…？）
・PayPal画面は PayPalが提供するソースコード埋め込めばおk（JS） ・ユーザがPayPalアカウントを持っていなければ送金時に登録画面に。 ゲストとして進めることもできる？
●課題 ・アダプティブペイメント単独では使えない →キーを取得したところから処理が始まっているので、他の部分からスタート ・送金者が金額設定できるのか ・お金受ける側は特に処理しない？ だとすると受け取りました的な処理加えられない…？ ・JSってRailsにつっこめるのか…？ Coffee Script…？ →コード書き始める姿が想像できない
●WebPay https://webpay.jp
・Ruby/PHP/Java/Python用のライブラリ ・クレジットカード課金 ・イメージ
・料金体系
※テスト環境の利用は無料
・ドキュメント（ruby） https://webpay.jp/docs/api/ruby#charges
・導入企業 freee、レター、WANTEDLY、WHILL、Crocos、gamba！
・情報発信 Facebook：https://www.facebook.com/webpay.jp 開発者ブログ：http://engineering.webpay.co.jp 「WebPayをRailsから利用するサンプルアプリケーション、WebPay Closetを配布しています」http://engineering.webpay.co.jp/2014/06/17/webpay-closet/ GitHub：https://github.com/webpay/webpay-ruby
●Yahoo!ウォレット http://business.wallet.yahoo.co.jp/support/api.html
・API一覧 リダイレクトURL生成、セッション情報参照、決済、マーチャント計算、注文前確認、通知、注文管理 ・導入事例 http://business.wallet.yahoo.co.jp/casestudy/index.html
●CyberSource http://www.cybersource.com/ja-JP/products_and_services/creditcard/payment_services_api/
・イメージ
・できること http://www.cybersource.com/ja-JP/products_and_services/fraud_management/decision_manager/ プログラミング不要…？ ・結局何出来るのか、ドキュメントないのか。パッと見て情報整理されてないのはイケテない
●J-PAYMENT http://www.j-payment.co.jp/service/payment/card/developer.html
・作ってくれなくてもいいです
●SoftBank Payment Service http://www.sbpayment.jp/asp/system/api/index.html
・決済手段
・イメージ
・導入事例 http://www.sbpayment.jp/case/
・権力の臭いがしてなんとなく情報の出がよくなくて、レガシーな印象。あんまり調べたくない。
●参考図書 ・WEB+DB PRESS Vol.76（2013/8/24） 特集の１つにWEB決済 Web決済入門 PayPal、WebPay、iOS/Androidアプリ内決済の導入方法 本特集では、Webサービスやスマートフォンアプリで行う課金についての最新動向を解説します。初めて課金を導入しようと思ったとき、どのような課金手段があり、どれくらいの手数料がかかるのか、どのような事前審査があるのか、どのように実装すればよいのか、セキュリティはどうなっているのかなど、わからないことだらけです。本特集ではこれらの全体像を整理し、クレジットカード、iOS/Androidアプリ内課金、PayPalなどの主な課金方法についての実装ノウハウも解説します。
→これで全体感見てから細かく入った方がよいかもしれません http://www.amazon.co.jp/WEB-DB-PRESS-Vol-76-五十嵐/dp/4774158747