私も以前に使ったことがありますが、最近GMO決済に詳しい方に教えていただいたことで、リンクタイプのケースで勉強になったことがありましたのでメモ。
ドキュメント通りに実装したので、当時はそんなこと考えたこともなかったかも。
リンクタイプのRetURL（決済結果戻し先URL）ではRetURL側でのプログラム処理は確実ではないということを聞きました。
（決済後に決済結果戻し先URLに遷移する前にブラウザを閉じたりするとRetURLにPOSTされないというケースも考えられるため）
このため結果通知プログラムというのがある。
正常応答が確認出来なかった場合に約60分毎に5回指定したアドレスにPOSTしてくれる機能がある。
このPOSTに対する応答によって再送されるか判定される。
ただし、RetURLにPOSTされるデータとは異なるので取得できないものもあるので注意
詳しくは【結果通知プログラム（インタフェース仕様）】を参照
つまり
RetURLと結果通知プログラムの二段構えで結果判定をする必要がありそう。（実際に試したところ結果通知プログラムの設定を行ったら両方とも実行されたので結果通知プログラムのみで判定を行う方法が良い。）
RetURLのみで実装すると決済は行われたがアプリケーション側では完了していないので途中で登録を辞めたという判定になってしまうことが希にあり、かなり厄介とのことです。
ドキュメント類はテスト環境申込 登録をしてログインを行ってから確認することができます。
追記
実際に使用してみると
リンク決済結果受け取り（RetURL）
と
結果通知プログラム
は両方実行されてリンク決済結果受け取り画面（RetURL）より先に結果通知プログラムの方が実行されたので、リンク決済結果受け取り画面（RetURL）では処理を行わず、（完了画面の表示のみにする）結果通知プログラムで処理を行う方法で良さそう。
デバッグ
リンクタイプでシステムエラー（エラーコードもわからない）になってしまう場合のデバッグ方法
共通のエラーテンプレートのbodyに以下を追加してみる（これでエラーコードが出力される）
{insert name="debug_showAllVars"}
その他
-
ドキュメントの
弊社指定のIDとはShopIDのこと -
結果通知プログラムはテスト環境ではpt01.mul-pay.jpから実行されました。
本番ではこれがp01.mul-pay.jpになったりするのでアクセス制限の際には注意が必要です。