体験の出口を争う日本のキャッシュレス、体験の入口から作る中国のキャッシュレス｜shao (SAWADA Sho)
キャッシュレス化を進めている日本ではクレジットカード、Suica や Edy などの電子マネーにQRコード決済が加わり、レジでの決済手段の多様化が進んでいます。一方、中国ではQRコードを店の入口から活用し、顧客のスマートフォンを用いた購買体験の向上が図られています。 店に入る前からQRコードが渡されるここは深圳の「緑茶餐庁」というレストラン。美味しい浙江料理が評判で入店待ちの客が多くいます。 筆者が到着すると整理券を渡されました。 この整理券にはQRコードがついていて、これを WeChat で読み取ると「二維火点餐」という Web サイトに接続されます。 QRコードは顧客ごとに異なり、整理券番号と紐付けられています。そのため、QRコードを読み取るだけで待ち行列の進捗がわかります。順番が近づくまで店を離れていても大丈夫です。 事前注文とチェックイン先ほどのQRコードからは待ち行列の進捗だけで
クレジットカード決済の実装 - Diary
クレジットカード決済の実装 、一番いいのは Amazon Payment Paypal みたいに完全に外部のサービスとして構築されていてそこにリダイレクトして処理が行われるものを使うことだろう。 ただ Amazon アカウントもってないだとか Paypal アカウント持ってないだとかいう人は結構多いし、 B2B 系だとさらにいろいろ面倒は増すと思う。国内だと GMO ペイメントがアカウントなしで GMO 側のドメインで決済できるものを提供していたと思うが使ったことないのでよく知らない。こういうタイプは最も望ましい、と思う。 まあ他にもそういうリンク型みたいのいろいろあるだろ。専門じゃないからよく知らん。 非通過型決済とでもいうのか、クライアントサイドで決済を行なって決済事業者としかクレカ情報をやり取りしないタイプの決済サービスが最近は出てきている。 Stripe がそういうのだと代表的なの
APIのエラーハンドリングを見直そう - WebPay Engineering Blog
ここ数ヶ月にわたって、WebPayはAPIのエラーにまつわる変更を少しずつ行ってきました。 それに付随してドキュメントも拡張しましたが、変更の背景について十分に説明できていない部分がありました。 この記事では、最近のエラーに関連した変更の背景を紹介し、今後どのようにエラーをハンドルすべきか説明します。 記事の内容は執筆時点のものであり、今後同じようにエラーやAPIの変更を行うことがあります。 変更があっても記事の内容はその時点の内容を保持し、ウェブサイトのドキュメントのみ更新します。 必ずウェブサイトのドキュメントを合わせて参照し、手元で動作確認を行ってください。 エラーはなぜ起きるのか WebPayのAPIは、リクエストされた操作ができなかったときにエラーを返すように設計しています。 可能なかぎりエラーにならないような設計、実装を心がけていますが、エラーは絶対に避けられません。 例えば、
Paypal新少額決済サービスMicropaymentsの衝撃とは | Token Spoken
Paypalが、ついに自社の少額決済サービスであるPaypal Micropaymentsを提供開始しました。 残念ながらまだ日本語コンテンツはありませんが、既に円決済には対応しているようです。 通常、Paypalの円決済では手数料が3.6% + 40円ですが、このMicropaymentsを使用するとその手数料が5.0% + 7円となります。 それだけではわかりにくいので、通常手数料とMicropaymentsの手数料をグラフで比べてみることにします。 Paypal通常手数料と少額決済手数料の比較 手数料の分岐点を計算すると、 X * 3.6% + 40 = X * 5.0% + 7 X = 2357.1 すなわち、単価2,357円までの決済であれば、このMicropaymentサービスを使うと手数料が下がると言う事です。 たとえば、単価（ticket price）が1,000円の場合、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IDEA * IDEA
