Yeah I saw that, but I think I remember another thread where you more or less asked the same question. I may be wrong, it could've been somebody else.

What I am saying is that by using an XML DOM you will be able to pass more info than what a URL allows. The receipt will be handled in the same way as you are doing now, you will just have more data.

>>Passing an XML DOM to the Send() didn't work for you?
>See message#1067079
>
>I did not even consider pass it as an object - it would be a good idea - by I am a gremmy with ASP - so my project passed it as a string that ASP eventually associated with an XML object.
>
>The "trick" required that the ASP create a server instance of MSXMLDOM2.Document. The instance had to be created before the receiving parameter was accepted as an ASP "REQUEST". I am probably misleading myself in believing that an XML string service will allow my client app to pass more data to an ASP service than a URL.
>
>I also note that even though the XML was passed to ASP as a string, the DOM needed to load the request (as though it was a file). Let me clarify, the ASP loaded the XML string as a file, oXML.Load(REQUEST), rather than what I thought it should "do", an XML string load oXML.LoadXML(REQUEST)
>
>So I think the oHTTP.Send(myXMLString) creates a file on the server - either that - or ASP oXML.Load(REQUEST) behaves differently.
>
>I am about to do tests with real data. So we'll see if we found something that will really work, or something that looks looks right, only to be overwhelmed by the "real world"!