あらまし

業務で、PayPalを用いた定期決済のフォームを作成しており、その際にPayPalに顧客情報を渡したいなーという願望があり、色々と調べた内容をメモ。
当記事の対象はウェブペイメントスタンダードのみとする。
ウェブペイメントプラスでも同様の仕様だったかと認識しているが、実践で使ってないため言及は避ける。APIやエクスプレスチェックアウトは別の方言。

PayPalに顧客情報を伝える必要性

PayPalを利用したことがない顧客が多い環境に導入する際、PayPalアカウントの取得を同時に取得していただきたい（１回買いきりの即時決済であれば、確かクレジットカード番号入力のみでアカウント不要だったと思うが、定期決済の場合はアカウント必須となる）。

しかし、アカウント取得のためには、PayPal側でも住所、電話番号などの顧客情報を（前のフォームで入力したにも関わらず再度）入力せねばならず、ユーザービリティを損ねる。

そこでPayPalでは、ショップ側からPOST送信にて顧客情報を受け取り、顧客がPayPal会員登録する際に生じる入力の手間を省くことを可能にしている。

いうまでもない注意事項

POST送信というかそもそも、外部のサーバに情報を渡す際は、バリデーション・例外処理を注意深く行うこと。
また法規的な意味で、会員登録を同時に行うために個人情報の送信を行う旨を、顧客に公知すること。と同時に、運営側のセキュリティポリシー、個人情報保護方針に抵触する部分がないか確認し、存在した場合は策定者と喧嘩すること。

(まずはこいつを見てくれ) PayPal登録フォームに事前入力可能な項目

PayPal資料顧客のPayPal登録フォームを事前入力

実際のフォーム設置例が書かれており、送信できる項目もわかる。
以下からは先のリンク内容を踏まえて述べる。
なお、以下にてシングルコーテーション内はPOST送信にて使用するパラメータ、ダブルコーテーション内はパラメータに代入する文字列を意味している。

勘所1: 日本の環境ならば 'last_name'(姓) 'first_name'(名)の順で

PayPalはアメリカでの利用が最大前提として設計されている為、当然名前の順序は日本と逆になる。
「そりゃそうよ」とはいうものの、案外とうっかりしやすいポイントで、フォームに姓名が逆で登録されている、なんてことが多々ある為、注意しておこう。
ちなみに上記のリンクには注釈で(英数字のみ)となっているが、全角は普通に入るのであった。

勘所2: 'zip'で郵便番号を渡せると言ったな。あれは嘘だ

2016-09-14現在のPayPal側の登録フォームだと、'zip'(日本3桁) と 'zip2'(日本4桁) に分割されており、かつ'zip2'がPOST送信にて渡せない状況だ。3桁だけ渡せても中途半端なので、いっそのこと送信しない方が良いだろう。
たぶん、実装がおいついてないんだと思う。釈然としない。

勘所3: 'lc'に国名コード、'currency_code'に通貨コード、'night_phone_a'に電話番号の国コード

日本であれば、'lc'には"JP"、'currency_code'に"JPY"（円決済の場合）、'night_phone_a'に"81"を入れておこう。
越境ECなど海外在住の顧客も相手取る場合は、国名選択時に、これらを連動させておく必要がある（通貨コードに関しては"USD"一択という手段も。仕様と相談）。
ただし、米国が相手の場合、'night_phone_a'には、米国の電話番号のエリアコードを入力せよとのお達しがある。というのも、そもそもこの項目は元々が自宅用の電話番号（の市外局番）の為に設定された項目だという歴史的な経緯がありそう。つまり想像の範囲。
従い、米国からの顧客には、その辺も分岐でなんとかするか、いっそのこと開き直って'night_phone_a'に米国の電話番号コード"1"を入れてしまう方が良いのかも。要相談。

勘所4: 'night_phone_b' に電話番号をハイフン無しで流し込み

米国であれば'night_phone_b'には3桁の局番、それ以外なら国コード以外の番号を入れろと書いてある。
制限が数字（の文字列）のみなので、事前に作成したフォームからは、ハイフンを削ることや、フォームに入力された文字列の結合など、PayPal側に合わせた加工が必要。
携帯電話番号のような11桁も入るので安心。

勘所5: 文字コード絡みで決済ページの接続に失敗することも。UTF-8なら必見

最近のページのエンコードは大体UTF-8かと思うが、PayPal側では、日本からの送信は未だShift_JISが基準だと考えているらしい。
そのためUTF-8で書かれたページからPOST送信すると、PayPal側でエラーを吐いて取引拒否される。
これはPayPalビジネスアカウントでの設定で解決可能。詳しくは "PayPalボタンの言語コード化" でぐぐれ。

また、POST送信時に明示したければ、'charset'に"UTF-8"などを記載すれば良いのだが、特に要らない気もする。metaタグにちゃんと記載あるよね、普通は……。

勘所6: 生年月日は渡せない

PayPal側のフォームで生年月日欄が存在したとしても、生年月日のデータを渡すことができず、顧客に自前で入力して頂く他はない。
これは生年月日のデータがクレジットカード関連のデータと強く紐づく為、これらは敢えて入力しなければならないような設計となっている。ということを空気で察した。

従い、顧客がPayPal会員登録の際に記入しなければならない項目は、クレジットカード関連の情報（生年月日含む）と、郵便番号（解せぬ）が最低でも含まれる。

勘所7: 「ウェブペイメントの自動復帰」を設定中なら、'return'に独自の戻り先URLを指定できる

PayPal側で決済が正常終了した際、任意のページにリダイレクトしてくれる機能がある。そもそも、してくれないと辛い。設定は以下参照。
http://qiita.com/PayPal_MTS/items/d3e4e8bc5d1ab555f2bb
（っていうかこのユーザ、stackoverflowや知恵袋にも同じ内容でマルチポストしてるけど大丈夫なんかしら……）

上記の設定のままだと、PayPalの設定画面で設定した戻り先URL１つに転送されることになるが、決済ページの種類により、別のURLに飛ばしたいと思索するは世の常人の常。
その場合、POST送信時、'return'に独自のURLを指定しておくとよい。

ちなみに当方では、PayPalの設定画面で指定するURLに、エラーページを指定している。ショップ側のフォームで戻りURLを指定することを強制する運用だ。

勘所7-1: 'return'の戻り先URLは、「http://」「https://」から指定すること

「//www.url...」と指定して死んだばかりだったので、一応追記補足。