Webサイトで課金決済するためにはどうすればよいか、調査

2016年5月5日

投稿者自身が課金設定できる「Webメディア」及び「サービス」
・ユーザがWebページへ投稿した内容を少額課金するプラットフォームを作成したいのですが、どういう手段があるでしょうか？

2018年12月23日

不特定多数の投稿者が、Webで有料コンテンツを公開する仕組みを作りたい
・Webで投稿者が有料コンテンツを公開する仕組み。そういうAPIはありますか？

2018年12月23日

不特定多数の投稿者が、Webで有料コンテンツを公開する仕組みを作りたい
・Webで投稿者が有料コンテンツを公開する仕組み。そういうAPIはありますか？

お金の流れ
・読者 が コンテンツ作成者(投稿者かつ課金を設定する人) へお金を支払う際、手数料を徴収するようなイメージ
・API公開されている個人間送金サービスを使用すれば、やりたいことが出来る？

2018/12/23時点の思考

調査した結果分かったこと

「(Webサービス)事業者」が「決済代行サービス」を利用して、「サイト利用者」に対して課金する仕組み
・おおよそ理解できた
・多分、導入できるだろう

「投稿者」が、「閲覧者」に対して課金する仕組み
・理解できない
・「不特定多数の(Webサービス)利用者(投稿者)」が、「閲覧者」に対して課金する仕組みは理解できない
・投稿者自身が課金設定できる「Webメディア」及び「サービス」を実際に利用してみて、機能を推定しながら実装するしかない

2019/1/12時点の思考

クラウドファンディング

投資型
・規制法律のハードルが高過ぎて無理
・対象外

寄付型
・やりたいことは一つある。検索
・落合陽一がReadyforで約2千万円集めているが、あれは筑波大准教授の肩書も持つ落合陽一だから出来ること
・【第２弾】デジタルネイチャー「計算機的多様性」の世界へ（落合陽一（筑波大准教授・学長補佐） 2018/02/21 公開） - クラウドファンディング Readyfor (レディーフォー)
・一般の人がどんなに素晴らしいことを言っても、「研究環境を作るための寄附募集」分野では成立しないと思われ
・実際に自分がやるとすれば、まず詳しい人を雇うことから始めることになる。それを「寄付型クラウドファンディング」で行うことは難しい
・その道の第一人者自らが「寄付型クラウドファンディング」で募集するなら話は別かもしれないが……

購入型
・消去法により残るは購入型しかなくなるのだが、新たな疑問が生じる
・「クリエイター支援プラットフォーム」とは何が異なるの？

・クリエイター支援プラットフォームは、法律的にはクラウドファンディン
・クリエイター支援プラットフォームは、法律の規制を受けますか？

Next

フェーズ1.「仕組み」あるいは「決済代行そのもの」。実装候補
・個人事業主が導入可能な決済系サービス2次選考過程第1段階
・Open Challenger

フェーズ2.「他社が提供している決済代行の仕組み」を利用したサービス。参考候補
・投げ銭サービス
・クラウドファンディング

8日

個人事業主が導入可能な決済系サービスを1次選考
・通過数9。Coiney、LINE Pay、クロネコwebコレクト、イプシロン決済サービス、pring、PAY.JP、paymo biz、Stripe、Kyash

12日

Webサイト「決済用語」を、新規作成&公開
・これまでこのサイトへ投稿していた内容を分離

クリエイター支援プラットフォームは、法律の規制を受けるの？
・クラウドファンディングで言えば、何型に該当するの？

18日

Open Challenger 設置
・取り敢えず、動作確認してみる

20日

「個人事業主が導入可能な決済系サービス」の2次選考を開始
・先ずは「個人で導入可能な決済サービス」を試してみる
・Stripeアカウント登録
・Stripeデモ設置
・テストカードで決済しても、stripeのマイページ画面に決済金額が反映されない

21日

Stripe
・テストカードで決済すると、stripeマイページ画面に決済金額が反映されるようになる

22日

Postfix
・PHPでメール送信できようになる

23日

Postfix
・「PHPで送信したメール」の返信メールを、受信できようになる

24日

Postfix
・「MXレコード」「TXTレコード」設定

25日

PHPMailer
・Gmailのメールサーバを使用してメールを送る

26日

PHPMailer
・「Gmail」「Yahoo!メール」SMTP認証

28日

Stripe
・テストカードで決済すると、PHPMailer →「Yahoo!メール」SMTP認証経由で自動メール返信
・stripeマイページ画面に決済金額が反映される
・2次選考通過

paymo biz
・2次選考落選

Coiney
・2次選考落選

29日

PAY.JP
・PHPで作成したWebサイト上でテストカード決済すると、管理画面上でも決済金額が反映される
・2次選考通過

pring
・2次選考落選

クロネコwebコレクト
・2次選考落選

イプシロン決済サービス
・2次選考落選

30日

LINE Pay
・2次選考落選

Kyash
・2次選考落選

2次選考終了
・通過は、Stripe、PAY.JP

31日

Stripe
・1.Product → 2.Plan → 3.Customer → 4.Subscription

1日

Let's Encrypt
・ワイルドカード証明書の取得に成功したが、無料SSL導入に失敗
→ 従来の方法「$ sudo certbot --nginx」で、https化
※ConnectのリダイレクトURL指定は、https必須のため(より正確にはOAuth 2.0は、https必須のため)

2日

Stripe
・Connect処理後、stripeマイページ画面にて「アカウント連結」を確認

最終選考
・Stripe採用

3日

バックアップ
・「3.5インチハードディスク」＋「ハードディスクケース」ではなく、「外付けハードディスク」＋「ジョイントラック」で保存していくことを決定

4日

Stripe
・Connect動作確認
・redirect_uri指定
・curl_setopt_arrayで転送用の複数オプションを設定する。何度も繰り返して curl_setopt() をコールしないよう変更
・infoへ初めての問い合わせ。個人事業主について

5日

Stripe
・「json_decode(curl_exec($ch), true);」の返り値まで、コード確認

6日

PAY.JP Platform
・初めての問い合わせ。PAY.JP Platform の新規受付停止について

Stripe
・Connect動作確認。親へ入金 → 子へ送金
・購入者が提供者(親アカウント)へ1,000円支払うと、下記の処理を自動実行する
・提供者(親アカウント)は入金された1,000円の内、400円を販売者(子アカウント)へ送金する
・結果をダッシュボードで確認できた

7日

Stripe
・問い合わせ2回目。Connect カスタムアカウント手数料について

8日

Stripe
・問い合わせ3回目。Connect カスタムアカウント手数料について2

Stripe Payment
・設置してみた
・WordPress使用しているなら検討の余地はあるかも

Crebow Stripe JP Payment
・設置してみたが使い方が分からない
→ 導入見送り

WP-Members Membership Plugin
・Stripe対応しているみたいだけれども、詳細が不明
・「WordPress」×「Stripe」の組み合わせは、「WordPress」使う予定の人だけが検討した方が良いと思われ
・自分で作れる人にとっては、探すだけ時間の無駄かも

9日

Stripe
・問い合わせ4回目。Connect カスタムアカウント手数料について3

10日

Stripe
・Connect動作確認。子へ入金 → 親へ送金
・購入者が販売者へ1,000円支払うと、下記の処理を自動実行する
・販売者(子アカウント)は入金された1,000円の内、600円を提供者(親アカウント)へ送金する
・結果をダッシュボードで確認できた

11日

Stripe
・「Stripeプレフィックスあり設定値」確認
・Charge ID
・Customer ID

12日

Stripe
・「Stripeプレフィックスあり設定値」確認
・token ID
・Authorization Code

13日

Stripe
・問い合わせ5回目。トークン化について

14日

Stripe
・問い合わせ6回目。「Stripe.js & Elements を利用した非通過・非保持のトークン化」の流れについて

15日

セキュリティ
・「クレジットカードのトークナイゼーション」を理解できた
・驚くくらい簡単な仕組み
・どんな高等技術を駆使しているのかと思ったよ！
・「トークン」とか「トークナイゼーション」とか勝手に命名するのはどうなの？
・「トークン」… 既存の仕組みと被っていて紛らわしいのよ
・「トークナイゼーション」… 全然大した内容ではないよね。大袈裟なのよ
・「双方が保持している不可逆データ」を後で突き合わせているだけじゃん！
・理解するまで2日を要したよ

16日

Stripe
・問い合わせ7回目。Checkout利用時の「トークン生成タイミング」と「トークン生成場所」について

17日

Stripe docs
・Card Payments Quickstart ／ カード支払いのクイックスタート

18日

Stripe docs
・Checkout Client-only クイックスタート ベータ版 ／ Stripe Checkout public beta version

19日

Stripe
・問い合わせ8回目。Stripe Checkout public beta version について

20日

Stripe
・webhook … ファイル出力

21日

Stripe
・webhook … var_export()でファイル出力

22日

Stripe
・問い合わせ9回目。Checkout beta version で、webhookを受け取ると、client_reference_idがNULL

23日

Stripe
・「Payments ＞ Quickstart」の意味がようやく分かる。独自ページは1ページのみ。後は(Nextで)他カテゴリに属する既存ページを抜粋しているだけ
・「Payments ＞ COLLECTING PAYMENT DETAILS ＞ Checkout Reference」を訳している途中

24日

Stripe
・問い合わせ10回目。Checkout の Simple で、「data-zip-code="true"」追加した場合について
・問い合わせ11回目。テストAPIで、実際のカード番号を入力したらどうなりますか？

25日

Stripe
・Checkout Custom。「POST /v1/tokens」のデモ設置

26日

Stripe
・Checkout beta version の webhook で、'client_reference_id'を受け取る
・Checkout Custom docs 日本語訳完了

27日

Stripe
・「Payments ＞ COLLECTING PAYMENT DETAILS ＞ Stripe.js and Elements」を訳している途中

28日

Stripe
・「Stripe.js and Elements」デモ設置。「Stripeサーバよりクライアントへ返ってきたトークン」をPHPで受け取るまで
・問い合わせ12回目。IBAN要素を使用すると、日本でも顧客の銀行口座の詳細を取得できますか？

1日

Stripe
・「Payments ＞ COLLECTING PAYMENT DETAILS ＞ Card Element Quickstart ／ カード要素のクイックスタート」日本語訳終了

2日

Stripe
・ダッシュボードより手動で、「インボイスに紐づけられたメールアドレス」へ対して、メール送信
・問い合わせ13回目。決済成功時に、「請求に紐づけられたメールアドレス」に対して、メール送信したいのですが、

3日

Stripe
・ダッシュボードより手動で、「支払いに紐づけられたメールアドレス」へ対して、メール送信

4日

Stripe
・「Productオブジェクト」「Planオブジェクト」について調査開始

5日

Stripe
・問い合わせ14回目。Customerオブジェクトをcreateする際の"source"パラメータについて

6日

Stripe
・「Productオブジェクト」「Planオブジェクト」「Customerオブジェクト」の関係をようやく理解できた
・GUI経由ではなく、スクリプト経由で一つずつオブジェクト作成して、連結させてみることが大事

7日

Stripe
・Subscription新規作成。Subscription新規作成のために必要な各オブジェクトも、全てコードで新規作成

8日

Stripe
・PaymentIntent 学習開始
・問い合わせ15回目。PaymentIntent でエラー。カード番号に不備があります。

9日

Stripe
・全く進捗なし。学習開始以来、恐らく初めて
・「カード」「ソース」回答なし
・PaymentIntent は調べるも原因不明。「Mixed Content: This request has been blocked; the content must be served over HTTPS」が関係しているかもしれないが、原因と思われる「favicon」がどうしても見つからない
・明日、再度試してうまくいかない場合は、PaymentIntent を諦める
→ 11:42。無事解決した。原因は「入力場所間違い」だが、根本的に勘違いしていた。「名前」と「カード番号」を入力しなければいけないのに、「名前」欄にカード番号を入力して「カード番号」欄には何も入力せず送信ボタンを押していた。然るべきところに入力して送信したところ、無事成功した

10日

Stripe
・PaymentIntent 学習開始
・問い合わせ16回目。PaymentIntentの支払いで郵便番号入力を求められる。Radar rules の ZIP code を無効にしているのに
・「SCA」「PSD 2」「3Dセキュア」について調査開始

11日

Stripe
・問い合わせ17回目。カード情報を「card object」「source object」へ保存する違いについて
・問い合わせ18回目-2。Is there a way to check whether the object (such as the return value from the API) is implements ArrayAccess?
・PaymentIntentの支払いで郵便番号入力を求められないようにするためには、「elements.create」する際、「hidePostalCode: true」オプションを設定する
・「3Dセキュア2」「EMVCo」について調査開始

12日

Stripe
・「Q14」「Q17」回答に対する内容確認
・具体的には、「source object」「card object」「PaymentIntent」の関係性について調査
・現時点の感想としては、「PaymentIntent」と「source object」の組み合わせが最良だと思われる
・それにしても「PaymentIntent」が従来とはやり方が全く異なることに初めて気が付き、軽くショックを受ける
・これまで必死で学習してきた知識は、再入れ替えが必要というか…。まだスタートもしていないのだけれども……

13日

Stripe
・問い合わせ19回目。「PaymentIntents」と「Sourceオブジェクト」と「Sources API」の関係について
・問い合わせ20回目。「webhook」と「synchronous」と「Checkout beta version」について

14日

Stripe
・「Best Practices Using Sources ／ ソースを使用したベストプラクティス」日本語訳途中

15日

Stripe
・問い合わせ21回目。新規顧客作成時に新規ソースオブジェクトを添付したいのですが、No such token: src_xxxxとなります
・問い合わせ22回目。「新規Customerオブジェクト作成」と「'source'パラメータ指定タイミング」について
・問い合わせ23回目。イベントで「新しい支払元が追加されました」と表示されているのに、「支払元がありません」

16日

Stripe
・「Q22」「Q23」回答にショックを受ける。まあしょうがない
・問い合わせ24回目。After attaching the source to the customer object, how do I check from the customer object?
・新規Customerオブジェクト作成時に"source"パラメータとして、ソースID（src_xxxx）を指定
・既存Customerオブジェクトに"source"パラメータとして、ソースID（src_xxxx）を追加
・1人のCustomerオブジェクトに、"source"パラメータとしてソースID（src_xxxx）を3回指定
・"source"パラメータとしてソースID（src_xxxx）を複数追加している、既存CustomerオブジェクトのソースID（src_xxxx）を取得して表示

17日

Stripe
・問い合わせ20-1回目。About whether you need a webhook when payment is complete
・Customerオブジェクトを更新してdefault_source値としてソースを指定する(src_xxxx)ことで、default sourceを変更できる
・Customerオブジェクトとソースの両方を指定 … default_source値以外のソースID（src_xxxx）を指定してみる
・ソースを指定せずにCustomerオブジェクトをchargeすると、Stripeは顧客のデフォルトのソースを使用する
・CustomerからSourceオブジェクトを切り離す。試しにデフォルトのソースID（src_xxxx）を指定すると、他のソースIDが自動的にデフォルトとなる
・支払いを特定のCustomerオブジェクトに関連付ける場合、ソースが関連付けされていなくても、ソースでchargeリクエストを行うときにcustomerパラメータを含めることができる … 例えば、(Customerオブジェクトに関連付けされていない)4111111111111111のソースID（src_xxxx）を指定した場合、4111111111111111のソースID（src_xxxx）で支払いが行われるが、4111111111111111カード情報はCustomerオブジェクトに関連付けされない
・Charge::createする際、customereパラメータ指定する場合は、"source"パラメータとして、トークンID（tok_xxxx）を指定不可。これは恐らく、CustomerオブジェクトにTokenオブジェクトを関連付けられないため。Chargeオブジェクトをcreateする際、下記パラメータの組み合わせは不可だから
・Sourceオブジェクトについてはようやく理解できて来た感もあるが、今度はCardオブジェクトの必要性が分からなくなってきた

18日

Stripe
・ダッシュボードの顧客詳細ページの「支払元」欄自体が表示されなくなる
・Cardオブジェクトは、他オブジェクトとは異なりStripeオブジェクトと継承関係がない
・Cardオブジェクトは、Customerオブジェクトのsourcesプロパティ内にあるdataプロパティ内にリスト構造化されて配置される仕様
・問い合わせ25回目。Why is it an error to use “token_xxxx” not associated with a Customer object for payment?

19日

Stripe
・問い合わせ26回目。If you only accept credit card payments, are there any functions that can not be done with src_xxxx but only with tok_xxxx?
・「checkout.js」を使用する場合、あなた(販売者側)のサーバでは($_POSTで)'src_xxxx'を受け取ることが出来ない
・Stripe API ドキュメントの 表示形式が変更される。表示速度が改善されたみたい。見やすさは以前の方が見やすかった気もするが、しかし従来はクソ重かったので、この仕様変更は大歓迎
・問い合わせ27回目。ダッシュボードやAPIドキュメントの表示内容変更などを知らせるページはありますか？

20日

Stripe
・問い合わせ28回目。Sourceオブジェクトのusageプロパティのデフォルト値について

21日

Stripe
・問い合わせ28-2回目。What is the default value of the usage property of the Source object?
・「The latest improvements to Stripe’s new Checkout」メール受信。「Stripe's new Checkout」の説明ページが、documentation に組み込まれる
・Stripeエントリー45件。数が増えて見難くなったので親カテゴリへ昇格

22日 → 31日

旅行

1日 → 2日

旅行

3日

Stripe
・Connect日本語訳開始

4日

Stripe
・下記日本語訳途中
・Connect Account Types ／ Connectアカウントの種類

5日

Stripe
・下記日本語訳途中
・Using Connect with Standard Accounts ／ StandardアカウントでConnectを使用する

6日

Stripe
・問い合わせ29回目。日本で、Connect Customアカウント を導入している事例について
・「Connect Customアカウント 導入」を現時点では見送ることを決定。(ある程度の資金がないと)個人では、本人確認処理が難しいため

7日

Stripe
・Payments ＞ PREPARING FOR SCA ＞ Payment Intents 日本語訳開始

8日

Stripe
・Payments ＞ PREPARING FOR SCA ＞ Payment Intents ＞ Migration Guide 日本語訳開始

9日

Stripe
・Payments ＞ PREPARING FOR SCA ＞ Payment Intents ＞ Usage 日本語訳開始

10日

Stripe
・Payments ＞ PREPARING FOR SCA ／ Checkout (new) 日本語訳更新

11日

Stripe
・Using Checkout with Connect ／ Connectでチェックアウトを使用する。PHPコードが掲載されていないため省略。恐らく作成中なのだと思われ。後で要チェック！
・Migration from legacy to new Checkout ／ レガシーから新しいチェックアウトへの移行。PHPコードが掲載されていないため省略。恐らく作成中なのだと思われ。後で要チェック！

12日

Stripe
・公式ドキュメントが、一部ではあるが日本語訳されていることに気が付く
・Checkout (new) client の挙動再確認。「ファイル出力」及び「Webhook」周り

13日

Stripe
・問い合わせ30回目。Checkout (new) の「Checkout Server Quickstart」の「Step 2: Add Checkout to your website」について

14日

Stripe
・問い合わせ31回目。ダッシュボードでの「支払い作成」の見方について

15日

Stripe
・問い合わせ32回目。Webhook のエンドポイントから適切な値を返さなかったときの停止措置について
・問い合わせ31-2回目。キャプチャの意味が良く分からないのですが、「2段階支払い」における「支払い実行」のような意味ですか？
・問い合わせ33回目。CustomerオブジェクトのcreateSourceメソッドのAPIドキュメントについて

16日

Stripe
・問い合わせ34回目。I could create a Stripe account with the code below, but where can I find the code for this create method?
・Accountクラスのcreateメソッド呼出 → Createトレイトのcreateメソッドが実行されている
・「新しいStripe Checkoutがベータ版ではなくなったこと」を通知するメール「The new Stripe Checkout is out of beta」を受信

17日

Stripe
・「新しいStripe Checkoutがベータ版ではなくなったこと」に対する対応
・『Stripe Q30。Checkout (new) の「Checkout Server Quickstart」の「Step 2: Add Checkout to your website」』は、jsにクリックイベント記述を追加し、セッションIDパラメータを文字列で指定するよう変更したら、期待した通り動作するようになった

18日

Stripe
・「Checkout (new) ＞ Checkout Server」で Subscription デモ作成

19日

Stripe
・問い合わせ35回目。「Payment Intents API」で、3Dセキュアなどの認証手順を(顧客が)使用しないことは出来ますか？
・「Stripe Payments ＞ PREPARING FOR SCA ＞ Payment Intents」更新に伴う、日本語訳修正対応

20日

Stripe
・「Migrating to Payment Intents with Automatic Confirmation ／ 自動確認による Payment Intents への移行」日本語訳開始

21日

Stripe
・「Payment Intents Usage Guide ／ Payment Intents 使用ガイド」日本語訳更新

22日

Stripe
・Payment「6.シングルページアプリケーション」など、デモ設置
・「Creating PaymentIntents ／ PaymentIntentsを作成する」日本語訳更新

23日

Stripe
・問い合わせ36回目。What is the difference between “stripe.handleCardPayment (clientSecret)” and “stripe.retrievePaymentIntent (clientSecret)”?
・「Verifying Payment Status ／ 支払い状況の確認」日本語訳開始

24日

Stripe
・問い合わせ37回目。PaymentIntentで支払いを行った後、成功画面を表示させるためにはどうすれば良いですか？
・問い合わせ38回目。Difference between “paymentIntent.status === 'succeeded'” and “payment_intent.succeeded event of Webhook”
・「Payment Methods API」日本語訳開始

25日

Stripe
・(挙動確認のため)PaymentMethod オブジェクトを新規作成
・サーバ経由 … \Stripe\PaymentMethod::create()
・クライアント経由 … await stripe.createPaymentMethod()

26日

Stripe
・「Saving Payment Methods ／ 支払い方法を保存する」日本語訳開始

27日

Stripe
・問い合わせ37回目-2。How do I redirect to the success screen after receiving the “payment_intent.succeeded” event via webhook?
「PaymentMethodオブジェクト」と「Customerオブジェクト」の関係

28日

Stripe
・問い合わせ39回目。I want to check the processing for the 'success_url' parameter of the 'Checkout \ Session :: create () method' in the Git-Hub code
・Stripe Link 確認

29日

Stripe
・Stripe サービスの方針(大まかな仕様)を決定する

30日

Stripe
・GitHub「marketplace」PHPコード選考

1日

Stripe
・昨日から「Marketplace」デモ設置を試みている
・エラー解決できず、苦しんでいる
・特定バーチャルドメインのみ「エラーログ出力先」＆「エラーログレベル」を変更した結果、ようやくエラーログを確認できるようになったが、解決の糸口が見えない
・今日のQにAがなければ、明日は別のデモ設置を試みるつもり

2日

Stripe
・「Marketplace」デモを、サブドメインではない環境へ再度設置してみる
・問い合わせ40回目。Displayed correctly when accessing / register, but an error occurs when accessing / files
・laravel-stripe-connect。普段から Laravel 使用している人が「Stripe Connect」使用する際、ヘルパーとして利用するもの。設置したデモは削除
・yclas。php.ini で short_open_tagをonにする必要がある。全PHPファイルが影響を受ける変更を行いたくなかったため、デモ設置しなかった

3日

Stripe
・「Using Checkout with Connect ／ Connectでチェックアウトを使用する」の日本語訳およびデモ設置
・問い合わせ41回目。NginxとPHPの組み合わせてログ確認できないエラー
・Aを得られなかった場合、Marketplaceは自動的に終了

4日

Stripe
・「Migration from legacy to new Checkout ／ レガシーから新しいチェックアウトへの移行」の日本語訳およびデモ設置
・Stripe サービスリリースへ向けて。新プロジェクト「P46」発足。ベースとなるプロジェクトを「P42 … 旅行記」に決定。取り敢えず、サイトコピー設置

5日

Stripe
・「Migration from legacy to new Checkout ／ レガシーから新しいチェックアウトへの移行」の日本語訳終了
・目指すサービス「note」に決定。案1.技術系に特化。案2.デザイン系に特化

6日

note
・「販売者」「購入者」へのサイト登録への導線を、noteが分けていない理由が不明なため、実際に登録して確かめてみる

7日

note
・noteアカウント構成は2種類。「無料会員」「プレミアム会員」。※「有料記事を販売できる会員」が「プレミアム」という区別ではない
・予想していたよりも高機能。というよりは芸が細かい。サービスを「ブラッシュアップ」し続けているのだろう、という印象を受ける
・「読者」は「クリエイターの口座」へ直接お金を振り込むわけではない
・「Stripe Connect Customアカウント」を導入できれば似たようなサービスも構築可能だが、「Standardアカウント」では色々制約も多い。どう頑張ってみても同じようなサービスは構築できないと思われる
・noteを目指したサービスを構築するのではなく、「Stripe Connect Standardアカウント」で出来ることの内、取り入れることが出来るnote仕様をうまく組み込むことを検討していく、といった感じになると思われる

8日

P46
・Postfixのメール送受信機能の全容を掴むことは難しい。何となくは出来ても…
・1サーバをバーチャルドメインで運営している場合 の Fromメールヘッダ の問題
・案1.PHPでfrom指定して送信専用メールとして処理する。詳細ヘッダを確認されると発信元を特定されてしまう
・案2Yahoo!メールのSMTP認証経由でメール送信する
・問い合わせ。「メールアドレスのfrom」と「送信メールアドレスごとに HELO パケットを対応させる」について
・問い合わせ。送信専用のメールアドレスについて

9日

インターネット接続不可に陥る
・原因は、光ファイバー回線の接続コネクタ破損だった(10日判明)

10日

P46
・(Yahoo!メールの)SMTP認証経由でメール送信する機能(PHPMailer デモ6)を、新規登録に組み込む

11日

P46
・問い合わせ。mailxコマンド と SMTPサーバ と MTA について
・HTMLでメール送信するよう変更(リンクをクリックできるようにしたかった)
・リンク先表示は、クエリパラメータが付与された長いURL。noteを参考にした
・登録完了画面が不親切なので、案内用のリンク追加
・具体的には、ヘルプコンテンツとしてガイドページを作成。そのページへのリンクを追加

12日

P46
・ナビUIへも、ヘルプコンテンツであるガイドページへのリンクを追加
・ナビUI表示。「アカウント登録」から「新規登録」へ変更。2行名は表示されないため
・ログイン直後に遷移する一覧画面「/status」で発生するエラーを修正。SELECT list is not in GROUP BY clause and contains nonaggregated column
・ログイン直後へ遷移する一覧画面「/status」の名称を「一覧」から「マイページ」へ変更
・「P41」「P42」「P46」プロジェクトにおけるナビゲーション表示がおかしかったので、「カテゴリ」及び「詳細ページ」の「h1」「h2」周辺を修正

24日

P46
・「URL一覧」作成開始
・ガイドページ作成に辺り、参考とするページを決定

25日

P46
・ヘルプセンタートップページ作成

26日

P46
・ヘルプセンター／サイトについて
・ヘルプセンター／マニュアル
・問い合わせフォーム

27日

問い合わせフォーム単体デモ
・「valueと値を組み合わせた配列」で送信することは出来ない

28日

問い合わせフォーム単体デモ
・selectタグを多用した「お問い合わせフォーム」で、「集計」＆「メール返信」

29日

問い合わせフォーム単体デモ
・一応完成
・気になる点は、文言とCSSぐらい

30日

P46
・「お問い合わせフォームの日本語」をどう書けば良いかが分からない
・「お問い合わせフォーム単体デモ」をP46へ組み込む。フォームからの「メール送信」＆「受信」に一発で成功

31日

P46
・「ヘルプセンター／書く」作成

1日

P46
・「開発系」「デザイン系」の「二本立て」でいこうと思っていたが、「開発系」のみを取り扱うことを決定。「デザイン系」は取り扱わない。断念した
・ミッションを決定。「自分の専門分野ではない技術系情報」を得られるようにする

3日

P46
・「投稿フォーム」に「Markdown記法」を導入することを決定

4日

P46
・「ヘルプセンター／書く」作成中
・「参考にしているnoteヘルプセンター」は私には分かり難いので、再構成中

5日

P46
・一旦ヘルプページ作成を終了
・stripe導入部分など、そもそもの機能がnoteとは異なるため、ここからは自力で構築していく

6日

P46
・UI文言を決定
・日本語短表記(Gナビ用)、日本語全表記(ページ用)、英語表記

7日 ～ 9日

Windowsデスクトップパソコン不定期でフリーズ発生！
・何日間もかけて原因調査するも、結局分からずじまい
・返品

10日

P46
・「有料」「無料」をどう分別するの？ 問題

11日

P46
・「該当記事へ課金したユーザのみ」が「該当記事を閲覧できる」ようにしたい時のDBテーブル構成について

12日

P46
・「記事」と「課金ユーザー」を繋げる中間テーブル「status_user」を作成

20日

P46
・ようやくStripe導入箇所へたどり着く
・これまでは、Webサービスの従来機能(URL統一や公開非公開設定)で右往左往していた

23日

今日から再開
昨日までは、「Windowsトラブル」と「画像処理調査」を行っていた