写真即売的な仕組み

Just Idea

写真即売システム。

現状、 PC に落として DVD に焼いているけどどうにも面倒な気がしてならんので。

  • 事業者がデジカメで写真をとる
  • Eye-fi のダイレクトモードで、タブレットへ直接転送

Eye-fi ダイレクトモード

どこにいても、その場で転送。ダイレクトモードでEye-Fi カードからiPhone、iPad、Andoridデバイスへ写真や動画を直接転送することができます。

  • タブレットのアプリから Drop Box API を叩いて、ツアー参加顧客毎のディレクトリを作成（shikopon に代表者名を嘗めにいき、代表者毎のディレクトリを自動作成？）

[iPhone/iPad]Dropbox API を使ってみた　

ディレクトリの作成

“foo” というディレクトリをルートディレクトリに作成する場合は以下のようになります。

  • 写真が欲しい顧客はタブレットのアプリからメールアドレスを入力（ディレクトリと紐付け）
  • 写真を閲覧して、欲しい写真を選択（ディレクトリに指定の写真ファイルを書き込む）
  • 後日事業者が一括送信をすると、該当 Dropbox フォルダのランダム URL が記載されたメールが登録アドレス宛に送られて、写真をシェア

事業者は課金したければ、現地で直接。

メール配信と引き換えでも…

こんなアプリちょい欲しい。つくるの簡単な気も。

が、こちらのマネタイズはアプリでの課金しか考えられん。

shikopon 決済について

「カード決済はできないの？」という問い合わせがありニーズは確実にあるのと（手数料を非常に気にする人もいたけど）、自分のマネタイズ（目指せ全件課金）の可能性からも shikopon での決済について改めて確認をしたのでまとめ。

iFrame で表示した、事業者の HP 上の予約台帳システムの外部出力カレンダ上で Pyapal での決済まで行うことで、Paypal を通じた消費者からの入金を事業者と shikopon の 2者に分けることは可能そう。

Paypal の API でより複雑な決済フローも実現可能 - アダプティブペイメント - 

たとえば、 従来の決済手段では難しかった、一度に複数の相手と決済することも可能に。シンプルなソーシャルネットワークの決済システムから、複雑な給与支払いシステムまで、アダプティブ ペイメントAPIなら決済シーンにあわせ、様々な決済手段を提供します。 

PayPal API導入・活用ガイド

1対1のアカウント間ではなく，複数のアカウント間での柔軟な決済を実現することができるAPI群です。購入者からの支払いをECサイトとアフィリエイターの間で売上を分け合う仕組みを１度に実装することができます。

クレジットカードでの直接のオンライン決済の場合、国内では原則できないことになっている。（包括契約は無理で、自分が決済代行者になるしかない。）

いわゆる決済代行問題の考え方について

P.18

○我が国においては、「枝番」は消費者トラブルに関する責任が不明確となるおそれがあることを踏まえて、 原則禁止。このため、国内のカード会社(アクワイアラー)は、決済代行業者を通じて自らが直接枝番の審査・ 管理を行っている。

P.19

○カード請求明細書上、請求元の名称は「決済代行業者の海外子会社名」または「決済代行業者(日本法人)名」 となる。

クレジットカード決済を前提に手数料を想定して単純比較すると、Paypal のほうが安い。Paypal で実装しても、手数料を決済毎に自分も手数料をとることができそう。

Paypal の決済手数量

国内ビジネス 2.9%-3.6% + 40円

Chained Payment で、shikopon がアプリとして課金することができそう。

Adaptive Payments Developer Guide

P.22（Chain Payments）

In this example, the primary receiver receives $100 from the sender’s perspective. The primary receiver actually receives only $10 and passes a total of $90 to secondary receivers, Receiver 2 and Receiver 3. 

PayPal、秘密の新APIで生後間もないAmazonの支払いサービスを潰しにかかる

5.Chained Payment（連鎖支払い）：PayPal支払いが実行される際に、アプリが手数料を徴収したり、金銭を与えることができる

天候不順等による、事業者理由でのキャンセルへの対応は下記でできそう。

takahashifumiko.com

CampFireとかGroupon系のサービスがそうなのですが、PayPalの返金機能が60日であることを利用し、「先にお金を集めておいて、必要額集まったらリリース」という機能に対応したいと思います。本来の利用法とは違いますし、PayPalには仮売上を計上する機能もあったとは思うのですが、どうやらPayPalアカウントを持っているユーザーにしか対応していないようなんです。返金機能は常に提供されているので、これを悪用してこの機能を実装してみようかと。60日以内に必要な金額が集まらなければバルク処理で返金を行うという凶悪仕様ですね。

水谷さんの資料にある Refound_API でも大丈夫そう。

Rails で Paypal

Refund API で支払いの返金

下記関連の API 等については改めて確認。

1.予約管理システム→Paypal への決済金額の引き渡し

この利用例通り使えるのであればできそう。

この Chained Payment の利用例だと、事前に Paymal に商品登録をしない決済例のように見える。（つまり、金額の引き渡しができないと決済できない）

例えば、航空券とホテル、レンタカーの予約を扱うオンライン旅行業者のアプリケーションがあったとする。送り手には主たる受け手である旅行サイトしか見えていない。しかし、旅行業者サイトでは、その支払い金額を自社の手数料と、他業者が提供するサービスの実費とに分割することができる。PayPalは送り手のアカウントから金銭を差し引き、主アカウントである旅行サイトと、副アカウントである他の受け手にそれぞれ入金する。

再び水谷さんの資料。

Rails で Paypal

P.19 みる限り、primary_receiver を事業者、primary_receiver を shikopon として、primary_receiver の amount に、金額を代入すればいけそう。

ここみても同様にいけそう。

ただ、下記の記載があり予約者の Paypal アカウント作成が必要な可能性がある。

http://レスポンスでpayKeyというのが返ってくるので、それを付加したした以下のようなURLを参加者に投げるhttps://www.sandbox.paypal.com/webscr?cmd=_ap-payment&paykey=＜返って来たpayKey＞[ブラウザ]参加者はブラウザでPayPalにログインして支払いにOKを出すこの時点でサービス（Primary）に支払いが起こる

Paypal ウェブペイメントプラスで等で可能な、クレジットカード情報のみでの決済ができない可能性がある。

と、そもそも予約者にメール配信して、予約者がその URL からの決済を終了だと、

【自動化の為には】

  • メール配信時点では、shikopon 上では仮予約扱い
  • paypal  で決済終了で、shikopon 上の予約情報が支払い済みに変更される

【問題点】

  • 自動化をおこなわないとすると、事業者からすると、Paypal の決済確認が必要で銀行振込の確認の手間と変わらずメリットが無い

【確認事項】

  • Adaptive Payment を利用し、画面遷移で予約者にその場で決済を完了させることができないか？
デベロッパーガイドには、Adaptive Payments は Guest Payment （Paypal アカウント無しでクレジットカード情報のみでの決算トランザクションの完了）をサポートしているとの記載。Complete なので、メール配信後の URL からの決済も無し。

Adaptive Payments Developer Guide

P.59

Guest Payment

Adaptive payments supports guest payments, which are payments using a sender’s credit card without logging into PayPal to complete the transaction.The sender is not explicitly identified as a PayPal account holder during the transaction and is not required to have a PayPal account.

Each receiver of a guest payment must be a verified PayPal Business Verified or Premier Verified account holder.

PayPal handles guest payments in the same way that it handles explicitly approved payments. Instead of logging into PayPal to complete transaction, the sender provides credit card information on the PayPal payment screen: 


同資料 P.27 Embedded Payments を読んでいると、ミニブラウザが開いて自社サイト上での Paypal決済が完了する。


2. 発注一覧を事業者にみせて、キャンセル操作をしてもらう

下記方法で可能。

- 事業者に Paypal アカウントに入って操作してもらう。

- shikopon で用意した決済一覧の画面から、Refund API を叩いて返金

　　> 事業者情報に紐づいた、Paypal ID/PWD が shikopon 側に必要

3. 住所や氏名などの入力省略（もしくは、予約管理システム→Paypal へ引き継ぎ）

- shikopon 側では住所／氏名を聞かず、Paypal に入力させる業務的な回避は可能

ビジネスサイドとして、下記を改めて確認。

1. 事業者ニーズ咀嚼のため、カード決済をなぜしたいのか改めて確認。（無断キャンセル？振込確認の手間？手数料の許容範囲は？）

2. 現状、Web 経由でどの程度の予約件数があるか？（口頭確認、shikopon 0.5 or 1.0 導入で確認）

++ メモ ++

決済をするのであれば、（原則的に）予約申し込み -> 予約確定とする必要があり、予約申し込みを API で shikopon に直接入力する必要がある。（メール配信、マニュアル shikopon 入力は原則ダメ。）

【確認事項】

- 水谷さんの件はどういう業務で行っているか？

- システム構成は？（教室運営者のデータと Palpal ID/PWD の持ち方）

= カレンダ表示 =

API Server: shikopon API -> 事業者サーバ

= 予約登録 =

API Server: shikopon API -> shikopon Server

= 決済 =

API Server: paypal API  -> 事業者サーバ  

 > 事業者情報に基づいた Paypal Id/Pwd が API サーバ側に必要
“
三越伊勢丹は衣料品や化粧品に強い伊勢丹、中元・歳暮などの贈答品の注文が７割を占める三越のサイトを一体化する。それぞれの通販サイトの利用者は伊勢丹が30～40代、三越は40～50代が中心となり、11年度の取扱高は合計80億円だった。サイトの統合により、12年度は100億円以上を狙う。
そごう・西武や三越伊勢丹、通販サイト一本化　使い勝手高める　：日本経済新聞

クルーグマン「緊縮の底意」（NYT，2012年5月31日） - left over junk

「緊縮屋」どもに自分たちの喩えのダメさ下限を突きつけると，彼らはほぼ決まってこんな台詞を断言に立てこもる：「ですが，政府のサイズを小さくすることが肝心なんですよ」

さて．こうした断言は，経済危機そのものが政府縮小の必要性を実証しているんだという主張といっしょに出てくることが多い．でも，それはあか らさまにまちがってる．いちばんうまく嵐を切り抜けた欧州の国々に目を向けてみよう．そのリストの上位に入っているのは，スウェーデンとかオーストリアと いった大きな政府の国々じゃないか．

また，他方で，保守派連中が危機以前にもてはやしていた国々に目をやろう．イギリスの大蔵大臣にして現行の経済政策を設計した人物でもある ジョージ・オズボーンは，アイルランドのことを「可能性の芸実の輝ける実例」だなんて言っていたんだよ．その一方で，カトー・インスティテュートはアイス ランドの低税率を称えて，他の工業国も「アイスランドの成功から学ぶ」ように望んでいた．

このように，イギリスにおける緊縮への原動力は，実は債務や赤字をめぐるものなんかじゃあ全然ない．債務パニックを口実に利用して，社会プログラムを解体してやろうって話なんだ．そして，もちろん，これはアメリカでいままで起きてきたこととそっくり同じだ．

“
ビッグデータはウェブだけのものではないし、ソーシャルネットワークは現実のメタファーに近づきつつあり、ニコニコも超会議で実体化してしまった。もはやウェブならではの、ウェブに始まってウェブに終わるようなサービスというのは少なくなってきている。ウェブがフロンティアであるにはウェブならではのものが常に考案されていなければならない。今だに治外法権的な匿名の世界が崩壊することで、ウェブ文明は現実に完全に取り込まれると思うが、その日は当分来ないだろう。そんな中で、まだ未知のサービスが生まれる余地はあってほしいと思う。
第2次インターネット開拓時代の終わりとこれから - novtan別館
“
目を転じて現在のモバイル・ネットワーク環境を見ると、Wi－Fiアクセスポイントが拡充してきている他、基地局の分野でもフェムトセルを中心とした小セル化が進行している。これらの主な目的は急増するデータ・トラフィックへの対策だが、ロケーション・ベース・サービスの精度を向上させるには各エリアの単位が小さければ小さいほど都合が良い。フェムトセルでは数十メートル、5GHz帯を利用するIEEE802.11acでは80メートル程度、60GHz帯を利用するIEEE802.11adでは10メートル程度と可及範囲が狭い上に高速通信が可能である。このようなモバイル・ネットワーク環境は、Jenson氏の言う「ジャスト・イン・タイム」のインタラクションやAppleの特許内容を実現するための促進材料となる。
アプリの終わりの始まり
“
　「現在の第1世代のクラウドゲーミングでは、(ハードウェアを)1対1にしなければならない。1ユーザーに対して、1コンピュータ、1グラフィックスカードで、サービスを提供するため、それなりにコストが高く電力も大きかった。しかし、Keplerアーキテクチャでは、まず効率が高いために半分の消費電力でレンダリングできる。また、ビルトインされたハードウェアビデオエンコーダのおかげで、エンコードもオフロードできる」。 　「さらに、仮想化によって、1サーバー当たり1ゲーマーではなく、8ゲーマーまでを効率的にサポートできる。そのため、コストを下げて電力消費も半分に下げることができる。Keplerなら、ゲーム配信のコストを、Netflixのような映画のストリーミングのコストに近づけることができる。それによって、例えば、月10ドル程度のサブスクリプションで多数のゲームを楽しめるようになるだろう」。
【後藤弘茂のWeekly海外ニュース】 ゲーム機に挑戦するNVIDIAのGPU仮想化
“
昼頃から外に出て、雪で遊んで夕方から旅館で飯でもつついて、月曜朝には出るみたいな感じになっちゃう予定。子供もまだ昼寝と食事が 3時間おきくらいだから午後がっつりみたいなわけにもいかず、移動もおやつだのおむつだので結構バタバタするからゆっくり目で、そもそも旅行に行く目的が能動的というより家事しなくていいみたいな受動的な理由なんです。毎日ルーチン回すだけでひーひーいってるんで何もしないでテレビ見れたらそれが旅という感じ。温泉旅館で見る火曜ワイド劇場なんかが贅。自分ちでテレビ見れないから。（正月実家に帰って流行りのお笑いを見るんが目下の楽しみなのです。うひっ）
友人、変態にして天才、これも天才的な示唆
“
楽天は今年3月から、ファッション製品の委託販売を本格的に始めており、ブランドファッションの商品拡充を図っている。女性向けファッションの取り扱いが豊富なスタイライフと提携することで、スタイライフ経由でブランドとの取引を開拓していく可能性がある。ブランドファッション販売で先を行くスタートトゥデイに対抗する取り組みの一環と考えられる。
楽天がスタイライフの筆頭株主に ブランドファッション強化へ | Web担当者Forum
“
2012年1月から3月の3か月平均で QR コードやバーコードをスキャンした人は1,420万人以上おり、同地域にいるスマートフォン ユーザーの14.5％に相当するという。 どのような媒体に掲載された QR/バーコードをスキャンしたのかを調べたところ、最も多い回答は「紙の雑誌/新聞」の50.9％だった。2番目に多かったのは、「商品パッケージ」の38.0％。 その次は「パソコンで閲覧中の Web サイト」（28.8％）と「店舗に貼られたポスターや店舗で配られたチラシ」（28.1％）が並び、少し離れて「名刺や企業のパンフレット/カタログ」（12.2％）という回答があった。
欧州5か国スマホ利用者、QR/バーコード スキャン経験ありは14.5％ - インターネットコム