paypal と 電子書籍のダウンロード販売（その２）
その０．
購入ボタンはこんな感じ
item_number以外は必須。item_numberも、商品IDとして使うので、わたしの場合は必須。ユーザーがPaypalから戻ってきたとき・Paypalから即時通知があったときに、この商品IDでデータベースに照合する。
あらかじめ、Paypalで個人設定を仕込む。（以下とは別に、文字コードを日本語、UTF8に設定しておいた）
その１．
「ウェブペイメントの設定」
→自動復帰 オン
→復帰URL ユーザーが帰ってくるURLを設定
→支払いデータ転送（PDT） オン
→暗号化されていないウェブペイメントの受領拒否 オフ
購入ボタン自動生成で暗号化してないので、最後の設定はオフにしておく。
購入ボタンをクリックしてPaypalにいったユーザーが支払いを完了して「マーチャントに戻る」リンクをクリックしたら、復帰URLにパラメータを持って戻ってくる。それをスクリプトで解析する。以下はほぼほぼPaypalにあるサンプルコード（perl版）まんま。
戻ってきたら、GET でパラメータ＝トランザクションIDを取得して、Paypalの管理ページ、個人設定にある、auth tokenと、定型のコマンドとともに、PaypalのサーバーにPOSTでアクセス。
そこで取得できるcontentを改行でばらして一行ずつ、って先頭の行がSUCCESSであればOK。それ以外だと決済が完了していないので、どうなってるのか調べる必要がある。
というのが「PDT」というヤツ。
ところが、これはユーザーが「マーチャントに戻る」というリンクで戻ってくれないと、情報が何も取得できない。もちろん、Paypalの方からメールがくるし、Paypalの管理画面を見れば、取引状況はわかるので、調べてユーザーに返事を出すこともできる。
でも、今回やりたいのはダウンロード販売。
支払いが終わったらすぐにダウンロードページに行きたいよね…といいつつ、Paypalの「マーチャントに戻る」リンクがまるで目立たない。これじゃ、ユーザーはここでブラウザを閉じて終了、だろう。現に戻ってくる率は２０％もない、という記事もどこかで見かけた。なので、こちらは、もしユーザーが戻ってきたら、ありがとうございましたとか、確認にしばらくお時間くださいとか、表示を選択するためのモノとして使う程度。
そこで、以下のIPN（支払い即時通知）の出番。
その２．
「即時支払い通知（IPN)」
→通知URLを設定
支払いが生じたらPaypalから、通知URLあてに、パラメータを抱えてアクセスがある。それをスクリプトで解析。以下はサンプルコード（以下同文）
POSTされたパラメータをそのままに、コマンドを付加して、Papalに返すと、パラメータが正しいか間違ってるかだけ教えてくれる。パラメータが正しければ、料金を確認したり、トランザクションIDをチェックしたり。エラーがあったら、ログを吐き出し、正しければデータベースに登録してユーザーにダウンロードURL案内のメールを出す。
わたしはperlが少しわかる程度。それでもサンプルコードどおりに書けばほぼOK。ダウンロード販売ということで、データを受けてデータベースを使って商品を特定したり、ダウンロードURLを作ったり、というところがちょっと面倒だけど、難しいもんじゃない。
最悪、うまくいかないケースが生じても、Paypalからメールが来るし、Paypalの管理ページに行けば履歴を確認したりキャンセル処理ができるので致命的なことにはならない、はず。
それに、ダウンロード販売なので、面倒な在庫管理は不要。
ちなみに、無責任なことに、これを書いてる時点ではまだ本番でのテストはやってないので、あしからずご了承いただきたく。忘れないうちに自分メモ。
原稿があるなら、Paypalを使って、ダウンロード販売ですよ。たぶん、儲けるのは無理だけど、原稿を塩漬けにしてるぐらいなら、ネットに並べておいてもいいんじゃね、と。個人書店があちこちにできて相互にリンクできれば宣伝にもなって面白いんだろうから、お手伝いしますよー。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
paypal と 電子書籍のダウンロード販売（その１）
小説や漫画など、電子書籍を作るのは簡単。問題はどうやってそれを売るのか。
「ホームページに並べて・購入してもらって・ダウンロードしてもらう」
というのをどうすんだよ、てことで調べてみたメモ。
（ちなみに、作った電子書籍はDRMなしのPDFファイル）
結論から言うと。
Paypal のプレミア（以上の）アカウントを作れば、個人でも簡単にクレジットカードを使った小額決済ができて、ちょっと仕組みを作ればダウンロード販売までできる。
Paypalのアカウントは固定費不要。クレジットカード決済に審査も不要。一度の決済手数料は40円＋3.8%～。驚く手軽さ気軽さだ。
ショップとユーザーの流れ
ショップを訪れたユーザーがページにつけられたPaypalの購入ボタンをクリックすると、Paypalの支払いページに飛ばされて、そこで支払い手続きとなる。クレジットカード番号やメールアドレスなどをPaypalに対して入力することとなる。Paypalの支払い完了ページに、「マーチャントに戻る」というわけのわからないリンクが目立たないようあるけど、これをクリックすると、ユーザーはショップに戻される。戻ってきたユーザーは、ショップが用意した「ご購入ありがとうございました」ページなどを見る。
こちらでユーザーを誘導する。
ショップの裏方（たとえばデータベース）とPaypalの流れ
それとはまた別に、Paypalは支払いが生じたら、ショップにお知らせしてくるので、それを元に、ショップはデータベースに登録したり、ユーザーにお知らせメールを発送したりする。
こちらでショップとして売買の確定をする。
上記のやりとりで、なにか不明点があっても、Paypalの管理ページを開いてみれば全部わかるので、後でチェックして対応することも簡単にできる。
Paypalとのデータのやりとりでは
「誰が何を買ったのか」
だけがわかればOK。というかPaypalの役割はここまで。
ダウンロードURLを作って、そこでダウンロードできるようにするのは、ショップ側で作ることになる。
PDTとかIPNのサンプルコードなどの具体例は、以下次号、かな。
# ページは、あとは、本番でのチェックと原稿の校正だけ、となった。
# 七月にはオープン予定で。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
個人でできるネットの小額決済はPayPalだな
二日酔いでゲロりまくりの今日。…あれ？先週の土曜も同じ。で、そんなに飲んだ記憶もないのも同じ。ちょっと体調が悪いのかもしれない。
同人誌紹介ページを作ったのはいいけど
https://hino-yutaro.doncha.net/
通販の支払いをどうすんの？と。
ちょっと聞いてみると、同人誌の通販は、定額小為替の郵送とか、郵便振替が昔からよく使われているらしい。郵便局が意外にも便利だというのにちょっと感心。とはいえ、郵便局まで出かけなきゃいけないし、ネットで通販だし「購入ボタン」がほしいぜ、と調べてみた。
([2016/03/03 09:20:59]追記。今どきは、小為替は手数料が高くなったんで使われていない、とのこと)
PayPalがびっくりの便利さで驚いた。PayPalそのものは知ってたけど、どーせ英語だし使い勝手がわからんちんだろ、と。
https://www.paypal.com/myaccount/home
いつのまにやら、日本語の丁寧なサイトまでできていた。
メールでの決済
購入ボタン
ショッピングカート
の3種類が、固定費なし、無料で使える。決済手数料は40円＋3.8%～。
とりあえず、一番簡単そうなメール決済を試してみた。いや同じ単語連発で申し訳ない。本当に簡単で驚いた。
手順としては、
・お客さんからメールなりで、注文を受け取る
・PayPalの管理ページで請求書を作る
・PayPalから支払いページへのリンクのついたメールがお客さんのところに届く
・お客さんはPayPalのページに行って、PayPalのアカウントで支払うかクレジットカード情報を入力して支払いを済ませる
すべてのやりとりの段階でいちいちPayPalから確認のメールが飛んでくるので見落としもない、だろう。
これだけでも十分、だ。
購入ボタンをつけるほうがいいんだろうけど、同人誌紹介ページが、まるでECサイトみたいに見えるのもどうなんだろう、と思うので保留。
同人誌に限らず、個人がネットで展開するのに、PayPalはほんとに便利ですよ。眠っている原稿、塩漬けにされてる原稿があるなら、自分でネットに並べてみませんかー。
paypalと絡めるかどうかは扱うモノ次第だろうけど、ネットショップで本格的に始めるのも、ありですな。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
token secretの保存
しかたないんで、自前でセッション管理してみることにした。ユーザーのクッキーに記録するのはIDだけ。あとはそれを見て、DB_Fileに記録したaccess token と token_secret を引っ張り出す。
twitterの OAuth で使うtokenは永続性がある＝ずーっと使えるって話だからこんな面倒なことになるのだ。その場限りなら、ユーザーのクッキーだけでもまあギリギリOKだろうと思ったんだけど、ずっと使えるトークンだと、ユーザーのブラウザのクッキーに記録させるのはちょっと怖いじゃないか。で、ずっと使えるのに、クッキーをその場限りにしておいて、いちいちアクセスさせるとAPI制限に引っかかりそうだし。
てことでコードを書くだけ書いた。それでも、これでも、やっぱり。面倒くさいだけのOAuth使うヒマがあったら、Basic認証でイケよ、どうせセキュリティ的には目くそ鼻くそだぜ、と思う自分がいて、モチベーションが上がらないまま、週末なのですでに赤ワイン。
とはいえ、yahooとかmixiとかgoogleとか、OAuthで繋ぐサービスがあるから、調べておいて損はない、はずだよなぁ。
ちなみに縦書きtwitter、「たてたったー」は、まだBasic認証です。
[12/27 16:26:52]
哀しいほどハマったので、メモ。 perl の Net::OAuthは、わたしには手におえないことがわかった。ちょろっと改造しようにも、オブジェクト指向とやらで、わたしのスキルではソースを追えない。ので、OAuthも自前で作った。そこでのハマりのメモ。
その１．
署名は、メソッド（GETとかPOST）、リクエスト先のURL（パラメータは入れない）、URLにくっつけるパラメータ。の３種類を合わせて元になる文字列を作る。このとき、各々URLエンコードが必要なのだが、ハマったのがURLにくっつけるパラメータ。
key=value＆key=value形式でvalueをURLエンコードするのはいいんだけど、一度URLエンコードした上で＆で繋いでひとつの文字列にしたら、さらに全体をURLエンコードをする必要があった。2重にURLエンコードするような感じ。
その２．
署名に使うシークレットキーは、コンシューマーキーとアクセストークンのシークレットキーがある。twitterの場合なのかHMAC-SHA1の場合なのか調べてないのだが、アクセストークンを取得するまでは、当然ながらコンシューマーキーしか手元にはない。
形式は各々URLエンコードして＆で繋いで、それをキーに使用する。
コンシューマーシークレット＆アクセストークンシークレット
まだアクセストークンのないフェーズでも＆が必要だった。
「コンシューマーシークレット＆」というケツに＆をつけてキーにする。
https://developer.yahoo.co.jp/other/oauth/api.html
https://developer.yahoo.co.jp/other/oauth/signinrequest.html
さすが yahoo！実例が載っていて大助かりだった。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
OAuth で twitter にアクセス
OAuthをごそごそやってたのは twitter がそのうち Basic認証じゃなくて OAuthをAPIのクチにする、というの読んだから。
OAuthのわかりやすい解説は他の有用なサイトにまかせるとして、素人のわたしの理解をメモる。
やろうとしているコト。
現状。
1)縦書きtwitter（わたしの作ったtwitterを利用するサイト）がある。
2)縦書きtwitterは現状ではユーザーにtwitterのIDとPASSを入力してもらって、そのユーザーのタイムラインを取得、表示している。
※入力してもらった情報はユーザーのクッキーに保存。twitterに対してはBasic認証で繋いでいる。
この（2）の部分を、今後twitterが推奨するという、OAuthでの認証にしてみたい。
ざっくり大雑把な理解で流すけど。
1)縦書きtwitterにユーザーがアクセスする。
2)縦書きtwitterは、twitter本体に対して、縦書きtwitterは登録してありますよ、とお伺いをたてる。
3)twitter本体が、おう、お前久しぶりやな、ということがわかれば、ユーザーをこっちに寄こしなさい、ということで、ユーザーを twitterにリダイレクトする。
4)ユーザーは twitter に飛ばされて、そこでIDとPASSを入力して「承認」すると、ふたたび縦書きtwitterに戻される。
5)ユーザーは、twitterからもらう アクセスのためのtoken （IDみたいなもんだ）と、tokenを含めたアクセスを正しく認識するためのtoken_secret（パスワードみたいなもんだ）を持って戻ってくることになる。
6)縦書きtwitterは、ユーザーのtokenとtoken_secret＝IDとパスワードをどこかに保存しておいて、ユーザーに縦書きtwitterを使ってもらう。
※保存するのはたぶんクッキー。DBに保存したら、今度はそのIDとPASSがだれのものか、というログインが必要になるしねえ。
一応、OAuthで TL を取得したり、つぶやきを投稿したりできるようにはしたけど。はたして、これ、本当に安心で便利なシロモノなのか、そこんとこがまるで理解できない。
Basic認証は、IDもパスワードも平文で流れるのでセキュリティに問題があるのはよくわかる、けど。Basic認証にしろ、OAuthにしろ、少なくともアクセスしている間は、IDとパスワードをどこかに保存しなきゃいけない。この穴はBasic認証だろうとOAuthだろうと同じじゃないのか。見えないIFrameに仕込まれる程度のチャチなクッキー引っこ抜きに引っかかって「なりすまし」被害に合うのは防げない、ような気がする。
ユーザーにしてみれば、yhooなりmixiなり、ひとつのIDとパスワードを使いまわしできるので管理がラク、ってだけだったら（セキュリティ的に画期的になにかが変わったわけでもなさそうな）OAuthなんてこんな「ややこしい」手順を踏まなきゃいけないメリットは感じないんだよなあ。
OAuthの良さを誰か教えてくだされ～。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
OAuthでハマったのでメモ
twitter の OAuth認証を、と思ってごそごそ調べては試行錯誤。OAuthの一次情報、仕様を見ながら、自分でサインを作ればこんなにハマらなかったと思うんだけど、ラクしようと思って、perl の Net::OAuth ver0.20に投げたのが始まりだ。
以下のページを参考にさせていただいて、CPANからOAuthをインストールすればラクショーっぽいぞ、と。
https://blog.photoble.net/archives/category/memo/oauthtwitter
https://sayama-yuki.cocolog-nifty.com/blog/2009/09/twitteroauth-d7.html
甘かった。
その１．最初のリクエストで oauth_callback_confirmed が返ってこない
その２．twitterから、リダイレクトされて戻ってきたときには 401。認証されず、 oauth_verifier も返ってこない。
なんじゃそりゃ、と。延々ググりまくって今朝未明まで。今日も天気だというのに早起きして、ググる。…ヒットしないんだけど、どうやら OAuthの 1.0 と 1.0a の違いが原因っぽい。oauth_callback_confirmed も oauth_verifier も 1.0a から導入されたパラメータ、てことだ。OAuthで作られるパラメータを確認してみると、指定しているにも関わらず、callbackが入っていない。
Net/OAuth/で grep してみて OAuth.pm を読んでようやく解決。
request パラメータを組み立てるところに
一行入れるだけ、だった。
↑これが正しいリクエストヘッダー
CPANは便利なんだけど、素人芸の、ブラックボックス、コピペ使いは限界があるんだよなあ。
ここが通ったら次はアクセストークン取得でそれの扱いをどうするのか、またググる、か。でも気力体力が尽きたので以下次号だ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
