We still having issues with this integration as some things are still very unclear.

The initial documentation link is very different to the advice given by xxx -http://www.pnpscada.com/webservices.jsp

We found a link to a web service definition in one of the pnp scada's wiki's pages which seems more in line with the advice given. Can we use this definition for the integration? https://sdg.pnpscada.com/soap/XMLVendServiceSoap?wsdl

Lastly which url and credentials do we then use to run the transaction, would it be  http://XMLVend.pnpscada.com/CreditVendRequest

Is there any way to do a customer or meter check?

Can you provide us with some test meter numbers?

Can we use the AdviceRequest for token recoveries?

Is this for token sales only or also for smart meters also? 

Transcribed from email

Hi x 

http://XMLVend.pnpscada.com/CreditVendRequest

CreditVendReq. authCred.password is die pnpscada password

the operator must be the user login

it will be set up when the XMLVend entity is added on pnpscada

and the originating IP is also then set up

then the CreditVendReq.meteridentifier must be the serial number

and the CreditVendReq.purchaseValue is the amount of cents to pay

then the reply is a  CreditVendResp

the  CreditVendResp.ClientId is the same as with the request it sent

as is the  CreditVendResp.terminal id

and the  CreditVendResp.msgid

the  CreditVendResp.respdatetime is the time of the transaction

            CreditVendResp.hasFault is true if there was an error

            CreditVendResp.Fault.faultnumber would be 99

and  CreditVendResp.fault.desc would be the error description in a string

otherwise, if  CreditVendResp.hasFault is set to false

            CreditVendResp.creditvendreceipt.transactions[0].credittokenissue.token.stscipher is the sts token

CreditVendResp.creditvendreceipt.transactions[0].credittokenissue.meterdetail.msno is the meter serial number

We do sometime have another kind of fault with a faultnumber of 98 also

OK

so that is essentially the XMLVend interface to use, and the meaning of the parameters and the returns

I hope it is clear. 

Hi L

> We still having issues with this integration as some things are still very unclear.
> The initial documentation link is very different to the advice given originally  -http://www.pnpscada.com/webservices.jsp

We have a great many APIs. I can understand that it could be confusing to people. The basic methodology we suggest is to find the API that is most comfortable to you, and then test it out on your own pnpscada login. You can get one from Rudie or create your own at sdg.pnpscada.com

> We found a link to a web service definition in one of the pnp scada's wiki's pages which seems more in line with the advice given. Can we use this definition for the
> integration? https://sdg.pnpscada.com/soap/XMLVendServiceSoap?wsdl

Yes, that is fine. It is a SOAP interface, to do payments. So you'll basically implement your own client code calling the SOAP service described in the '.WSDL' file as found at that address.

> Lastly which url and credentials do we then use to run the transaction, would it be  http://XMLVend.pnpscada.com/CreditVendRequest

Yes, that would be the operation to use on the service at e.g. http://sdg.pnpscada.com/soap/XMLVendServiceSoap

Of course the actual server would probably be akim.pnpscada.com, not sdg.pnpscada.com, or perhaps another pnpscada server, depending on which customer you're connecting for. We have about 50 servers out there that could be potential clients of yours. All of them would publish wsdls at e.g. akim.pnpscada.com/soap/XMLVendServiceSoap?wsdl

HOWEVER, you must create the XMLVend Payment Facility entity inside pnpscada to connect to. This entity must then be associated with the Ledgers and prepaid facilities referencing the particular meter serial numbers. (this enables us to have multiple networks of payment devices on one server, referencing different networks of meters, potentially for different clients)

Concerning the add dialog of the XMLVend entity,
If you don't know the IP or subnet of the incoming device/s, you can specify a network of 0.0.0.0/0
You can restrict on the operator name. This must be the same as the pnpscada login name used, or you can leave it out it you want to accept multiple operator names.

The important part of authentication is the part of the SOAP request that specifies 'opName' and 'Password'.

    ??AuthCred authCred = req.getAuthCred();

    ??opName = authCred.getOpName();

    ??password = authCred.getPassword();

That must correspond to a login and password you have created on pnpscada.

The next most important part is the Msno of the MeterIdentifier, which must correspond to the meter serial number.

After that, it is the PurchaseValue, which is specified in cents, right?

Then, if it is an STS Prepaid facility on pnpscada, we pass back the STS code, or if it was a wallet Prepaid facility on pnpscada we pass back an STS code of  00000000000000000000

And we pass back an error, if appropriate.

> Is there any way to do a customer or meter check?

Have you got a pnpscada login? Otherwise ask your reseller to create the entities on PNPSCADA for you to test with. Once the appropriate entities are created in pnpscada, you can try to 'pay' money into a ledger from your side, with SOAP.

> Can you provide us with some test meter numbers?

You typically create your own. See above answer

> Can we use the AdviceRequest for token recoveries?

Not at the moment no. We can add that development: what would be the important parameters you pass in? The dateTime and the uniqueNumber? 

Is that the same uniqueNumber that was passed into the original request? Is that also the same dateTime that was passed into the original request, or will it be a new dateTime?

And what would the parameters you expect back exactly please? I don't quite see where to put in the STS code, for example.

> Is this for token sales only or also for smart meters also? 

We can do both, it is up to you how you use it.

Hope that helps!