オンライン決済システムの連携エラーの特徴
連携エラーは、２つ以上のシステムの間でデータをやりとりする過程で起こります。そのため、単独のシステムの不具合とは異なり、原因の特定や対応の分担が複雑になる場合があります。まずは連携エラーの特徴を押さえておきましょう。
原因を一方に限定しにくい理由
連携エラーの原因は、すぐには判断できない場合があります。オンライン決済システム側か連携先のシステム側か、あるいは両者の間の通信かを見極める必要があるためです。自社で行った設定の誤りや、どちらかのシステムの仕様変更が影響していることもあります。
原因を一方に決めつけて問い合わせると、確認に時間がかかる可能性があります。エラーの発生日時や取引の番号、表示されたメッセージを記録し、双方の提供会社に同じ情報を伝えて確認を依頼しましょう。
連携エラーで起こりうる現象
連携エラーで起こりうる現象には、データの同期の停止、反映の遅延、一部の項目の欠損、同じデータの重複登録、認証エラーによる接続の失敗といったものがあります。処理の一部だけが失敗し、残りは正常に完了するケースも考えられます。
こうした現象は、画面上ではエラーとして表示されない場合もあります。定期的に双方のデータの件数や金額を照合し、ずれがないかを確認する運用を設けておくと、早い段階で異常に気付けます。照合で見つかったずれは、原因と対応を記録し、再発防止に生かしましょう。
ECカートシステムとの連携で起こりうる不具合
ECサイトでは、カートシステムとオンライン決済システムが連携して、注文と決済の処理を行います。両者の連携に不具合が生じると、顧客への影響が直接表れる場合があるため、起こりうるケースと対策を確認しておきましょう。
決済結果の通知の未達
決済が完了した結果は、オンライン決済システムからカートシステムへ通知されます。この通知が、通信の途絶やサーバの負荷、通知先の設定の誤りによって届かないと、決済は完了しているのに注文が未確定のまま残る可能性があります。
通知が届かなかった場合に、自動で再送される仕組みがあるか、管理画面から手動で再送できるかを確認しましょう。決済代行会社の管理画面とカートの注文データを照合する手順も用意しておくと安心です。
注文と決済の状態のずれ
カートシステムと決済側の間では、状態のずれが起こるケースがあります。例えば、カートで注文を取り消したのに決済の取消が行われない、決済側で返金したのにカートの注文状態が変わらないといった状況です。どちらの画面で操作したかによって、もう一方に反映されない仕様の場合もあります。
取消や返金をどちらの画面で行うかを社内のルールとして統一しましょう。連携で反映される操作と反映されない操作を、事前に仕様書で確認しておくことも大切です。ずれが見つかった際に、どちらのデータを正として修正するかも決めておきましょう。
システムの更新に伴う不具合
カートシステムやオンライン決済システムは、機能追加やセキュリティ対策のために更新される場合があります。一方の更新によって連携の仕様が変わり、これまで動いていた処理がエラーになる可能性もあります。
双方の提供会社からの更新の案内を確認し、影響がありそうな場合は事前にテスト環境で動作を確かめましょう。更新の案内を受け取る担当者を決め、関係者へ共有する流れを作っておくことが大切です。更新後しばらくは、連携の結果を通常より丁寧に確認する期間を設けると安心です。
販売管理システムとの連携でエラーが起きる場合
基幹システムの一つである販売管理システムと連携する場合、決済データを受注や請求のデータと結び付けて取り込みます。取り込みの過程で起こりうるエラーと、その対策を紹介します。導入時の設計と運用の両面から確認しましょう。
データ形式や項目の不一致
販売管理システムに決済データを取り込む際、日付の形式や金額の桁、文字コード、項目の並び順が取り込み先の仕様と異なると、エラーになる場合があります。受注番号の桁数や形式が一致せず、照合できないケースも考えられます。
連携の開始前に、双方の項目の対応表を作成し、形式の違いを変換する方法を決めておきましょう。サンプルデータで取り込みを試し、エラーが出ないことを確認してから本番運用を始めることが大切です。販売管理システム側の項目を変更する際も、連携への影響を事前に確認しましょう。
取り込み処理の失敗と重複登録
定期的な取り込み処理が途中で失敗すると、一部のデータだけが登録された状態になる可能性があります。失敗に気付いて処理をやり直した際に、すでに登録済みのデータが再度登録され、重複が生じるケースもあります。
取り込み処理の結果を通知する仕組みを整え、失敗した場合はどこまで登録されたかを確認できるようにしましょう。同じ取引番号のデータを重複して登録しない設定ができるかも、販売管理システム側で確認しておきます。
ITトレンドでは、最新の製品・サービスを多数比較・掲載しています。まず資料請求して、さまざまな製品の機能や特徴を比較してみてください。忙しい業務時間内でも、各社に問い合わせる手間なく、たった1回の入力（約60秒）でオンライン決済システムの一括資料請求が可能です。浮いた時間で、じっくりと製品を比較検討し進めましょう。
APIの呼び出し回数制限への対応
APIは、システム同士がデータをやりとりするための接続口です。オンライン決済システムのAPIには、一定時間内に呼び出せる回数に制限が設けられている場合があります。制限に達した際の影響と、その対応を紹介します。
制限の内容を仕様書で確認する
APIの呼び出し回数の制限は、製品によって有無や上限の値、単位となる時間が異なります。上限に達すると、呼び出しが一時的に拒否され、決済の照会やデータの取得が失敗する可能性があります。
API仕様書で、上限の値と、上限に達した際に返されるエラーの内容を確認しましょう。上限を引き上げられるか、引き上げに追加の費用がかかるかも、取引量の多い企業は提供会社に確認しておくと安心です。上限に近づいた際に警告が出るかどうかも、運用上の確認項目です。
上限に達しにくい連携に設計する
上限への到達を避けるには、連携の設計段階で呼び出しの頻度を抑える工夫が有効です。例えば、決済の結果を何度も照会するのではなく、決済側から結果を通知してもらう仕組みを使う方法があります。
上限に達した場合に、一定時間待ってから自動で再試行する処理を組み込んでおくと、一時的な拒否による失敗を減らせます。設計の内容は、開発を担う担当者や開発会社と相談して決めましょう。取引量が増えた際に設計を見直す基準も、あわせて決めておくと対応が遅れません。
会計システムと連携しても手作業が残る理由
オンライン決済システムと会計システムを連携すれば、仕訳の作業を減らせる可能性があります。ただし、連携しても一部の処理には手作業が残る場合があります。手作業が残りやすい部分と、その理由を紹介します。
決済手数料や返金の仕訳
決済代行会社からの入金は、決済手数料を差し引いた金額で振り込まれる場合があります。売上と手数料を分けて記録するには、入金明細の内訳をもとに仕訳を作ります。連携の設定によっては、この振り分けを手作業で行うことになります。
返金や一部取消があった取引も、売上の取消として処理する必要があります。連携で自動化できる範囲と、担当者が確認すべき取引を事前に整理しておきましょう。例外的な取引の件数を把握しておくと、手作業にかかる時間の見積もりにも役立ちます。
まとめて振り込まれた入金と売上の対応づけ
複数の取引分の入金がまとめて振り込まれる場合、どの売上に対応する入金かを照合する作業が必要です。会計システムが入金明細の内訳を取り込めない場合、照合は手作業で行う必要があります。
決済ごとの入金予定日と金額を明細で出力できるか、会計システム側で取り込めるかを確認しましょう。照合の手順を文書にまとめておけば、担当者が変わっても処理を続けられます。照合で差額が出た場合の確認先も、手順書に記載しておくとよいでしょう。
勘定科目や部門の振り分け
決済手段や商品の種類、部門ごとに勘定科目を分けて記録したい場合、連携の設定だけでは振り分けきれないことがあります。複数の事業や拠点の売上が同じ入金に含まれる場合も、配分の作業が残る可能性があります。
経理部門の記帳ルールを整理し、連携で振り分けられる項目と手作業で補う項目を明確にしましょう。ショップや決済手段を事業ごとに分けて設定できれば、振り分けの手間を減らせる可能性があります。会計システムの提供会社にも、取り込み時の振り分けの設定方法を確認しておくと安心です。
連携エラーへの備えを確かめたいオンライン決済システム
ECカートとの接続方法や、請求と入金のデータをどこで管理するかといった観点から、連携の仕様を確かめたい製品を紹介します。
ASJペイメント
- 3Dセキュア2.0・セキュリティコード・PCI DSS Ver4.0に対応
- EC-CUBE等ショッピングカート対応の決済モジュール・プラグイン
- 決済手数料3.1%～、初期費用0円でオンライン決済を導入
株式会社ASJが提供する「ASJペイメント」は、ECサイトやメール注文にカード決済を導入できる決済代行サービスです。EC-CUBEやWelcartに対応した決済モジュールが無料で提供されるため、ECカートとの接続部分を独自に開発する範囲を抑えられます。3Dセキュアやセキュリティコードによる対策を備え、PCI DSSに準拠しています。クレジットカードとコンビニ決済に対応したクラウド型のサービスで、対応カートの範囲は事前に確かめておきましょう。
サブスクペイ Standard
- クレカ、口座振替、銀行振込、コンビニ決済などの決済手段に対応
- カード決済の決済手数料は、業界最安水準の2.5%〜
- 一度登録すればその後の課金処理をすべて自動化
株式会社ROBOT PAYMENTが提供する「サブスクペイ Standard」は、毎月の課金と顧客管理を自動化する決済サービスです。一度登録した顧客への課金処理が自動で行われ、毎月の課金を人手で繰り返す作業を減らせます。クレジットカードや口座振替、銀行振込、コンビニ決済に対応したクラウド型のサービスです。会計システムとの間でどのようにデータを受け渡すかは、手作業が残らないかという観点で提供会社に確認するとよいでしょう。
PAY.JP （PAY 株式会社）
- ベンチャー向けや旅行業向けなど、料金プランが豊富
- 国際基準に則った強固なセキュリティでクレジットカードを保護
- オンライン予約やEコマースなど、多様な目的での導入実績多数
イプシロン （GMOイプシロン株式会社）
- 最短1営業日で簡単に導入することが可能！
- 40,000社以上の導入実績！申し込みはウェブで完結だから簡単！
- オンライン決済、ビジネスの成長に必要なサービスも提供！
Stripe （ストライプジャパン株式会社）
- 世界で100種類以上の決済手段に対応
- 高信頼性で高いセキュリティ
- 開発者向け高機能API
OricoPaymentPlus （株式会社オリエントコーポレーション）
- 多様な決済手段をワンモジュールで提供。
- 3種の接続方式から選択可能。
- PCI DSS準拠、カード非保持、3Dセキュア2.0対応。
ペイジェント （株式会社ペイジェント）
- カード情報の非保持化や3Dセキュアなどセキュリティ対策が盤石
- 締め日から最短5営業日で入金される迅速性
- 多数のECサービスに標準対応し円滑に導入可能
まとめ
オンライン決済システムの連携エラーは、設定や通信、データ形式、処理の上限といった複数の要因で起こる可能性があります。ECカートとは通知と状態の同期、販売管理とは形式の一致と重複の防止が確認のポイントです。APIは回数制限への対応、会計連携は手作業が残る範囲の整理を進めましょう。
連携先の提供会社と役割を分担しながら、エラーに早く気付ける運用を整えましょう。通知や再処理の仕組みを備えた製品を資料請求して、連携の範囲を比較してください。
