From 2922b22de0c028e066f8859d32ebea5bf67ccf63 Mon Sep 17 00:00:00 2001
From: ivan <ivan>
Date: Fri, 12 Feb 2010 23:44:15 +0000
Subject: [PATCH] don't return an error about changing the cust_main record to
 the user as a payment processing error, log a bunch of verbose stuff in this
 case so we can track down wtf is going on, RT#6955

---
 FS/FS/ClientAPI/MyAccount.pm | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/FS/FS/ClientAPI/MyAccount.pm b/FS/FS/ClientAPI/MyAccount.pm
index 927ebefb1..3dbc3649a 100644
--- a/FS/FS/ClientAPI/MyAccount.pm
+++ b/FS/FS/ClientAPI/MyAccount.pm
@@ -684,8 +684,21 @@ sub process_payment {
     $new->set( 'payinfo' => $payinfo );
     $new->set( 'paydate' => $p->{'year'}. '-'. $p->{'month'}. '-01' );
     my $error = $new->replace($cust_main);
-    return { 'error' => $error } if $error;
-    $cust_main = $new;
+    if ( $error ) {
+      #no, this causes customers to process their payments again
+      #return { 'error' => $error };
+      #XXX just warn verosely for now so i can figure out how these happen in
+      # the first place, eventually should redirect them to the "change
+      #address" page but indicate the payment did process??
+      delete($p->{'payinfo'}); #don't want to log this!
+      warn "WARNING: error changing customer info when processing payment (not returning to customer as a processing error): $error\n".
+           "NEW: ". Dumper($new)."\n".
+           "OLD: ". Dumper($cust_main)."\n".
+           "PACKET: ". Dumper($p)."\n";
+    #} else {
+      #not needed...
+      #$cust_main = $new;
+    }
   }
 
   return { 'error' => '' };
-- 
2.11.0