Jump to content


Corporate Sponsors


Latest News: (loading..)

Sagepay Form Error for US customers


  • You cannot reply to this topic
6 replies to this topic

#1 li_osc

  • Community Member
  • 18 posts
  • Real Name:Lisa
  • Gender:Not Telling

Posted 16 August 2010, 14:03

I am using the Sagepay Form module and when US customers try to book they receive this error message when they click confirm order

Error: MALFORMED: 3147 : The BillingState field is required.

or

Error: MALFORMED: 3148 : The DeliveryState field is required.

Any help or advise would be great!

Thanks

#2 satish

  • Community Member
  • 5,325 posts
  • Real Name:Satish Mantri
  • Gender:Male
  • Location:Nagpur(India)

Posted 26 August 2010, 13:26

View Postli_osc, on 16 August 2010, 14:03, said:

I am using the Sagepay Form module and when US customers try to book they receive this error message when they click confirm order

Error: MALFORMED: 3147 : The BillingState field is required.

or

Error: MALFORMED: 3148 : The DeliveryState field is required.

Any help or advise would be great!

Thanks

As per the SagePay protocol 2.23 specification the BillingState and DeliveryState values must be the 2 letters state codes only not a value in the address. Check the Protocol 2.23 documentation for more details.
or just trap the request and response sent and received from sagepay to analyze what is being posted and recd.

Satish
Ask for osCommerce value addon suggestion tips for your site.
Check My About US For who am I and what My company does.


#3 digitalTag

  • Community Member
  • 16 posts
  • Real Name:J.P.

Posted 20 January 2011, 17:48

I am having the same error from SagePay but i dont know how to fix it. I read some guy say that "ive looked into it and its not a problem with the module it was to do with my US zones...". Can anyone tell me what my zones should look like?
At the moment mine look like this;
zone_id - 12
zone_country_id - 223
zone_code - CA
zone_name - California

Does anybody have any ideas?

Thanks
JPA

#4 nick

  • Community Member
  • 175 posts
  • Real Name:Nick Rosenberg
  • Gender:Male
  • Location:UK

Posted 20 January 2011, 23:02

View PostdigitalTag, on 20 January 2011, 17:48, said:

I am having the same error from SagePay but i dont know how to fix it. I read some guy say that "ive looked into it and its not a problem with the module it was to do with my US zones...". Can anyone tell me what my zones should look like?
At the moment mine look like this;
zone_id - 12
zone_country_id - 223
zone_code - CA
zone_name - California

Does anybody have any ideas?

Thanks
JPA

It is a problem with the module and I think Sagepay only enforced this week as previous it worked even though the 2.23 protocol info has been around for a while. I spent a few hrs last night figuring this out and coded a quick fix for it. I have uploaded a fix to the sagepay form contribution page

Thanks

Nick

#5 digitalTag

  • Community Member
  • 16 posts
  • Real Name:J.P.

Posted 21 January 2011, 00:34

Thanks for the response. I've just given it a go and now i am getting this error.

This transaction attempt has failed. Please use the Proceed button go back to the web store from which you were purchasing. The details of the failure are given below.

Status: INVALID

Status Detail: 4006 : The TxType requested is not supported on this account.

Any ideas?

#6 digitalTag

  • Community Member
  • 16 posts
  • Real Name:J.P.

Posted 21 January 2011, 00:45

I seem to have got it working.

On line 292 you had

//$transaction_type = 'PAYMENT';
$transaction_type = 'DEFERRED';

So i just changed it back to the default one which was

$transaction_type = 'PAYMENT';

It now seems to be taking payments from US and UK (thats all i've tested and i need to get to sleep) with no error so now its time for it to be tested on live by customers.

Thanks alot for your help and i hope these post helps others in the same position.

DigitalTag

#7 nick

  • Community Member
  • 175 posts
  • Real Name:Nick Rosenberg
  • Gender:Male
  • Location:UK

Posted 21 January 2011, 19:23

Yeah - we use the deferred payment type so I guess that makes sense